Jump to content

  • Log In with Google      Sign In   
  • Create Account

Crawling with ideas

7 games in 7 days, day 5 finished

Posted by , in 7games7days, C64, Ludum Dare, Programming 07 December 2012 - - - - - - · 1,503 views
ld48, ludumdare, programming and 2 more...
7 games in 7 days, day 5 finished Woah. After sleeping only for 3 hours yesterday, having been to dentist and visiting my landlady, I was facing a pretty big wall, and nearly dropped the challenge. However, I did pull through. After I've decided to use Commodore 64 style graphics for my project, I could feel the excitement, and was really enjoying myself. Using the 16 colour VIC-II palette, and non-square pixels is fun, even if annoying to draw by hand.

Today I was working on an adventure game. I have decided against 3D, and later on against most graphics at all. The game was to be fully text based, and I managed quite ok I think. I wrote a tiny parser with couple keywords, I wrote a decent room system. Sure, the item system is a bit of a hack work, the console isn't working properly, and most of the graphics are just placeholder. But the game is complete adventure (even if a very simple one), from start till end, it that really makes me happy.

With this, the biggest hill in the challenge is over - I've finished the week. Now it's weekend, and I'll have plenty of sleep, and plenty of time to develop.I think I'll add all the graphics sometimes next week, to have this working fully as intended.

Mini post mortem:

What went wrong?
-Well, haven't ever coded adventure game before, I had no idea how to properly implement inventory, and ended up with clusterfuck that I would very much like to purge with a fire.
-Not enough time. Again, due to lack of experience, I had to spend a lot of time looking things up on internet, and the fact that I didn't start before 10 pm, due to my schedule for the day didn't help at all
-Not enough sleep. Sure, the coding kept me alive and happy, but this is not a good long term way to spend time. I plan to sleep a lot over next two days, and code sensibly, not till the broad daylight again.

What went good?
-Graphics style. I really enjoy it, and it made me attached to the monitor, even if by all rights I should be lying unconcious right now.
-Type of game. I always was an adventure fan, and writing one for myself for the first time really made me happy. I could insert some of myself into the game, and even though the final product isn't as big or as funny as Lucasarts/Sierra games, in my mind it feels great, because of what it could have been.

Oh god, it's 6:50am. I really lose track of time when I'm enjoying myself while coding. Will need a lot of sleep to regenerate from that.

How are we looking game-wise? Let's see.

- Shoot'em'up - done
- Platformer - done
- Puzzle game - done
- Racing game - done
- Adventure game - done
- Dungeon crawler
- Strategy game.

Oh right, here's the game.

And here is a list of the entries in the series:

Last Day summary and Challenge Post Mortem
Ludum Dare preparation
Day 6 summary
Day 5 summary
Day 4 summary
Day 3 summary
Day 2 summary
Day 1 summary
Series kick off

Good night, and have a nice weekend.

Solder of fortune ( yeah, sorry, that was a horrible pun ) megapost

Posted by , in C64, Electronics 26 March 2012 - - - - - - · 969 views
C64, POV
Woah. Today was another long day at the Hackerspace. It's 2:30 AM and I'm finally finished for the day and heading to bed. Just to write this post and it's finally sleepy time. This entry will be quite picture heavy, so those of you who are on 33.6kbps modems may want to take that into account ;). Seeing as it was a long day, the entry will probably quite long - a fair warning. You will however see a whole process of making a PCB, so maybe that's something cool enough to warrant reading through all of this ;)

First of all, guys at the Hackerspace shown me how to properly solder. Since I prefer to do my C64 work on the original machine, as opposed to the emulator ( the 'vibe' is different ;) ), I really wanted to set up one of the Commodores I have at home so that I can code on it. Unfortunately, using the plasma TV was right out, as the monitor cable for C64 is horribly short, and the 42" screen is not something you want to look at while sitting 1 meter from it. Because of that I was forced to code only on emulator. That isn't half bad, as rendering for example those fractals that I described in http://www.gamedev.n...ered-rendering/ took about 15 minutes on 2000-3000% speed of the original machine. Realising how long it would take to render those on real Commodore makes me shudder. Anyways, back to what I was talking about - even though it's slow, it's more awesome, and I want to code on it. So I got my hand on an old, small TV set that I could possibly connect to. The only problem, it didn't have S-Video output, and I had only cable with that output for C64.

Enter soldering! Quick google led me to pinouts.ru, site with hardware pinouts, cables schemes and connectors layouts ( according to their main site). The website had even a full pinout for the exact adapter I was looking for: http://pinouts.ru/Vi...er_pinout.shtml . After quick consult with Ben ( yeah, I guess I should start paying him tantiems or something Posted Image ), I understood what I need to connect where, I looted my box with old parts for cables, sat down and soldered. Here's my creation:

Posted Image

I am quite proud of it, as not only this is the first adapter that I made, but also it is first really usable thing that I created when I needed it, not just for fun. Guys at the HS shown me how to use multimeter, and I checked the cables - all seemed well. I tested it with connecting my Wii through it to the plasma TV, and the image was crystal clear. Sound was also good. SUCCESS! \o/. Unfortunately, it seems that my small TV that I want to use as a monitor for C64 can't be changed to get signal from SCART/EURO without a remote. That is a major setback, but I guess it's also an opportunity - I'll need to get my hands on some IR LED, find the datasheet for the remote in the internet, and emulate its behavior somehow, probably on some Arduino Posted Image.

Now that I started to solder and desolder ( is that even a word? if not, how do you call that activity?) , I went on a rampage. I salvaged any electronic parts that I found in our /dev/null - our bin for anything unused, with primary target being LEDs for my POV display. I found two juicy equilizer displays with plenty of colorful LEDs and cannibalized them. I also acquired quite a few resistors and other usable parts. Yeah, I know those are incredibly cheap, but it's really nice to have start budget of 0.0. It's always easier to make decision to start spending cash on a hobby that you know you're really into.

That or I'm just making excuse for being cheap and lazy Posted Image

Where was I? Oh yes. I got some parts for my POV display. The first prototype was just a CD that I put on top of a small DC motor, to test if it spins fast enough. And honestly, it did. After that I drilled some holes in it, soldered couple LEDs to it , attached them to breadboard with resistors and checked if they worked. And yes, they did. Here's how it looked:

Posted Image

To be quite honest the LEDs didn't work as the machine was spinning, due to the cables cutting through the air like bunch of whips. The prototype obviously needed some work ;).

After thinking it through and talking about it with my friends, I decided to replace the CD with a printed prototype board. It wouldn't have any fixed routes ( except for one ), so I could solder in and out things as I saw fit, start with prototype and grow bigger from that. I launched Eagle, a really cool CAD software that allows you to design boards. Btw: I use free version, which has a limit on board size, but the size that I get with it (100 x 80 mm ) is easily big enough for my needs right now. Anyways, Here's the printed schematic that I quickly put together, already on paper:

Posted Image

The dark circle in the middle will be place where brush with current will connect to the board - shaft of the motor will go through the very middle of the board and have ground connected to it, that I will connect back from board through a brush as well. It's not really circular, but I hope that won't cause much problems. Eventually, when I'll be designing dedicated PCB for this, it'll have proper shape. After the print was finished, I cut a piece of board that was bit bigger than the surface I printed, cleaned it properly, and put it through laminator couple times. After the mask got properly stuck, I put it into water for 5 minutes, took the paper off, and landed with this beauty ready to be etched:

Posted Image

Well, seems like the transfer process wasn't perfect, but it was good enough for my needs. Another thing I realised was just how freakin' small I made the holes. It was obvious that it'll be hard to solder properly with that tiny copper surface. Nevertheless, I was happy. The board was ready to be etched, I just needed to drill a hole in the side, and off to vat of blue magical chemicals it went:

Posted Image

*blob* *blurb* *bloop* it went for couple minutes, etching away the unprotected parts of copper, leaving only those that were covered with paint. Accidentally, the sign on the vat says 'do not drink'. It's smart, regarding we're dealing with CRAZY people in Hackerspace Posted Image. I would know, I'm one of them ;). Anyways, the vat did its job and couple minutes later I cleaned the board from the protective ink and had it in my hand - a real life, hand made by me ( well, some parts of it anyways ) PCB. Sweet! It may be not perfect, it may have some problems, but it's my baby ;).

Posted Image

Now only to drill OVER 9000 holes. Sheesh. Since it takes ages, I only drilled bunch of them to put necessary pieces in, I'll drill more as it's needed. And yeah, the sockets are so incredibly small that soldering is basically putting a bunch of soldering iron more or less connecting two dots you want to join, and then adding some more. And more. And more. With my noob soldering skills you end up with such hideous results:

Posted Image

But again, I'm not bothered by that, as it WORKED:

Posted Image

Yay, blinkenlights!

Join me next time, when I'll be hopefully adding the rotation to the device, maybe even add some small controller that will make the lights blink to make pretty patterns!

Dithered rendering

Posted by , in C64 08 March 2012 - - - - - - · 953 views
Today I continued venture in high resolution bitmap mode of C64's VIC-II. As I mentioned yesterday, I started adding colors. First attempt looked butchered, but that was obvious for me when I started working on it. I used iteration depth as color for pixels in the 8x8 char area, and it gave me these blocky results:

Posted Image

I decided to use dithering. Since I have 16 levels of depth ( not counting the escaping shape ), each 4 levels would have their own dither level. It was a matter of finding some free memory, and poking it with tons of chars that would represent the dithering mask. My goal was to create something like

Posted Image

so I opened up my binary calculator and found the following values:

poke 16192,0
poke 16193,34
poke 16194,0
poke 16195,0
poke 16196,0
poke 16197,34
poke 16198,0
poke 16199,0
poke 16200,0
rem end char one
poke 16201,170
poke 16202,0
poke 16203,170
poke 16204,0
poke 16205,170
poke 16206,0
poke 16207,170
poke 16208,0
rem end char two
poke 16209,85
poke 16210,170
poke 16211,85
poke 16212,170
poke 16213,85
poke 16214,170
poke 16215,85
poke 16216,170
rem end char three
poke 16217,255
poke 16218,255
poke 16219,255
poke 16220,255
poke 16221,255
poke 16222,255
poke 16223,255
poke 16224,255
rem end char four

The free memory I used ( 16192-16224 ) was placed immediatly after my screen memory space. I've played around a bit with the code and ended with this result:

Posted Image

It may not be perfect ( colors are still blocky ), but it's SOMETHING. Maybe later today I'll add color+background dithering for smoother color transitions.

See you later then!

VIC-II high resolution bit mapping mode

Posted by , in C64 07 March 2012 - - - - - - · 850 views
Today I stopped playing with the text mode and entered bit mapping mode ( or, for modern people - bitmap mode ).

VIC-II, C64's graphics chip allows for resolutions of up to 320x200. In text mode that display is divided into 40x25 ( 1000 continuous characters ), each of which is 8x8 pixels big. As I mentioned previously, the characters are stored as 8 bytes, with each bit being either or on off, and making the pixel respectively the color of the character or the color of the background.

This is all fine and dandy in text mode, but how does the high res gfx mode look like? First of all - in high res mode, each 8x8 pixel block can have only 2 colors, much like the text mode. The change is that not the color RAM governs it ( the 0xD800-0xDBE7 ), but the characters in the screen memory ( 0x400-0x7E7 ). How does it work precisely? Each byte consists of lower and higher 4 bits. Low bits are interpreted as the color for background ( off state ), high bits are interpreted as the color for foreground ( on state ). To have first char ( upper left 8x8 pixels ) have black background and white foreground, poke its position ( 1024 or 0x400 ) with 0 ( for black background ) + 16 * 1 ( for white foreground ). Green-blue would be 5 + 16 * 6. Etc. Btw, for color values refer to booklet, wiki page on VIC-II or any other source you can think of.

Ok, that's how the colors are picked. How about the bitmap itself? Well, things are bit complicated here. You designate a bitmap area, and poke it. Bitmap area is 8000 bytes long ( 8 bytes per 8x8 block, 1000 chars ), and it's stored on per-char basis. That means first 8 bytes are first character on the screen, next 8 bytes are the second character, and so forth. Makes for a really confusing plotting when you're trying to do some drawing.

It's not that bad though, and the C64 booklet is quick to help.

I converted yesterday's code to bitmap mode, and here's the result:

Posted Image

It took AGES to render ( minutes, even after turning emulator speed to 2500% of original C64 ). Clearly, it's because I've done it in BASIC and without any optimisations, but at a depth of 16 it looks really nice.

If anybody wants the code, here it is:

sc = 0: pc = 1
for i = 1024 to 2023
poke i,sc+16*pc
poke 53265,peek(53265)or 32
poke 53272,peek(53272)or 8
for i=8192 to 16191
poke i,0
next i
offset = 8192
for x = 0 to 319
for y = 0 to 199
ln= y and 7
by = offset + ro*320+8*ch+ln
bi = 7-( x and 7 )
x0 = ((x/320) * 3.5 - 2.5)
y0 = ((y/200) * 2 - 1)
iter = 0
maxiter = 2
a = 0
b = 0
if a*a + b*b < 4 then goto 27
goto 34
if iter < maxiter then goto 29
goto 34
atemp = a*a-b*b+x0
b = 2*a*b + y0
a = atemp
iter = iter + 1
goto 25
if iter > maxiter then goto 36
poke by,peek(by)or(2^BI)
next y
next x

Just add line numbers as your text editor shows them and you're ready to go. Oh yeah, if you're typing it on VICE, ^ symbol is the upper arrow and it's bound to DEL. And remember, to quit the GFX mode, use ESC-PGUP.

See you next time, when I'll be adding more colors to the high res image!

Also, I have found a website with over 2 GiB worth of old C64 books with awesome titles like 'Artificial Intelligence projects on C64', 'DIY robotics and sensors using C64', 'Make your C64 Sing', 'Start Programming with GORTEK AND THE MICROCHIPS' or 'Will you still love me when I'm 64' :DDDD

The website is here: http://www.bombjack.org/commodore/books.htm

C64 BASIC kinks

Posted by , in C64 06 March 2012 - - - - - - · 860 views
Next day of studying the VIC-II architecture and using BASIC to play around with it.

First, I managed to solve yesterday's problems - since the booklet I was reading from is, like I said, crappy quality, I tried peeking 53240 instead of 53248 ( 0xd000 ) for character ROM. Once I translated the values into hex, the mistake was easy to spot. Since each character consists of 8 bytes ( 8 lines of 8 bits ), the off-by-8 error caused each character to be off-by-one ( 0 instead of 1, A instead of B etc ).

After I fixed that, I managed to work on RAM character memory and create custom characters ( a smiley, to be precise :D ), and called it a day. Today I wanted to throw together a quick Mandelbrot renderer, start by putting character 81 ( a filled circle ) all around the screen and changing its color based on standard escape time algorithm. Unfortunately, I've been hitting a wall. Basically, I've been having problem with nested FOR loops. At first I thought that maybe something is off with the nesting depth, but I've figured out that C64 BASIC allows for up to 9 nested loops. Then I thought that maybe there's a problem with NEXT. Finally, I wrote incredibly simple test case:

10 FOR LCX = 0 TO 5
20 FOR LCY = 0 TO 5
60 END

The result, which caused massive wtf in my brain was:



And then a friend told me to try 'lx' and 'ly'. And it worked. Apparently, C64 BASIC only uses first two letters of a variable as an identifier, even though the names can be over 100 chars long. After this obstacle was down, the results were following fast. And when I say 'fast' I mean, 'it took couple minutes for C64 to render it in character mode' ;). Without further ado, pics!

Posted Image

And now back to studying the architecture, instead of faffing about ;)

Resuming development

Posted by , in C64 05 March 2012 - - - - - - · 631 views
I have finally returned to developing my C64 skills. I've set up a computer dedicated to that purpose, and now am able to play around with it. Currently following C64 programmer's reference guide 3 - programming graphics. I'm at the beginning, which is setting up charset. Unfortunately, the booklet with which I'm working is so old, I can barely read through some parts - the source scan mostly. Which means I have to write most of the code I'm copying couple times, so that funky things stop appearing.

Current part of the code should copy bit-by-bit charset from ROM into RAM, and make screen display chars from that. Effectively, nothing should happen visually ( it should use same charset as that in ROM ), but it seems I'm one off somewhere, which result in funky caesar-ciphred ( with offset 1 ) screen display Posted Image :

Posted Image

The only question I have to anyone out there is:

poke 52,48 : poke 56,48 : clr

reserves memory for my charset. What exactly is happening here? According to http://sta.c64.org/cbm64mem.html it sets pointer to beginning of string variable area and pointer to end of BASIC area to 48. Why would that reserve memory? How much memory is reserved? I don't like doing something 'because it works'. I'd prefer to know why ;).

Well, back to coding. See you soon!


Update: thanks to Ben, it's clear now:

17:13 <@benryves> mantis: I'm no expert, but if the string table is the last thing in BASIC memory then moving it down would allow you to use the space between the old value and the new value as scratch RAM without worrying about the BASIC interpreter overwriting it. BBC BASIC makes things slightly clearer by calling that variable HIMEM and letting you refer to it directly (so HIMEM=HIMEM-100 reserves 100 bytes).
17:23 <@benryves> mantis: The 6502 is little-endian. If we assume that the string variable area is the same as the "end of BASIC" (&A000) then that becomes &3000. Which seems odd (reserving 12KB?) :|

The 0x3000 is where I'm storing the charset in RAM. And now it all makes sense.

Fun with C64

Posted by , in C64 25 February 2012 - - - - - - · 897 views
C64, BASIC, Hackerspace
  • dithering
  • mandelbrotnoinner
  • colormandelbrot
  • fractal
  • mandelbrot
  • caesar
  • BASIC foolery

Finally, I have some time to work on my own projects!

I've joined local hackerspace, and with a friend we decided to revitalize couple old C64s (after some deliberation on platform - it was either that or ZX Speccy). At first we want to add some simple functionality like SD card reader, but eventually we want to have a portable C64. I recalled that Endurion was making a series on making game on this platform, so I started studying his code. I've noticed that however good that tutorial was, I'll be needing some more basic knowledge about the platform. I found some scene sites dedicated to making demos, and - most importantly - C64 programmer's reference booklets. Those things are full with explanation on why poking at some addresses will give me certain effects. Again, Endurion's journal is great, and I'd like to give him mad props, but it has some problems like at-will switching between decimal and hex numbers, adding to confusion of development on a new platform. Fortunately, now I have some outside resource to fall back to.

First couple days (weeks? depends how much time I can scrape) I'll be studying the internals of the machine and replicating Endurion's code while trying to understand it, and later I'll move to making simple oldschool demo (sin scrolling text, 3d tunnel, fake fire, the lot). Final goal is to write a game (demake of Skyrim to a side-scrolling platformer or Zelda clone) for our own handheld, while my friend does the majority of hardware job.

Today's image: fooling around with BASIC to understand C64 memory layout.

Posted Image

January 2017 »

1516 17 18192021