Hunchy (my first 2600 homebrew game)

[cd-w]

I have finally managed to finish my first Atari 2600 homebrew project.

The results should be attached to this message. It is basically a

version of the classic Hunchback game. I don't think this game has

appeared on the 2600 before?

 

The source code is included in the attachment (GPL licensed). There

are still a few graphical glitches, so I would welcome any suggestions

for improvement. I was hoping to make it a 1K minigame, but at

the moment it is a bit over 1.5K in size.

 

Please let me know what you think, and any suggestions for improvement.

 

Chris

 

BTW: There are 15 levels in total - I think they can all be completed,

but I haven't managed to complete the last 2 myself yet!

 

NOTE: The latest version can now be found here.

hunchy01.zip

Edited May 20, 2005 by cd-w

[+batari]

Excellent work! It's fun and challenging to play.

 

My suggestion is to enlist the help of one of the pixel artists here to make the characters look better. They can do some truly amazing things with 8-bit wide sprites, such as the "blocko" guy or the running man from this thread.

 

Other than that, I suggest scoring and/or an indicator of what level you are on, and limiting the number of men.

[+batari]

Another thing - in one of my games I had the same kind of graphical glitch for the player. It's probably due to doing the store to GRPx to late in the kernel. I understand that you want to try to do this store while the TIA is still in HBLANK if you can, which is the first 68 color clocks in the scanline (about 22 CPU clocks.)

[cd-w]

Another thing - in one of my games I had the same kind of graphical glitch for the player.  It's probably due to doing the store to GRPx to late in the kernel.  I understand that you want to try to do this store while the TIA is still in HBLANK if you can, which is the first 68 color clocks in the scanline (about 22 CPU clocks.)

837579[/snapback]

 

Yes, there is a bit of a glitch with the player for the first few pixels on the LHS. The write

to GRP0 happens on cycle 27 which is just a bit too late. I think I need to juggle things

around a bit in the kernel, or learn how to use the VDEL registers properly. Any

suggestions on how I can tighten the Kernel would also be welcome.

 

Chris

[vdub_bobby]

Yes, there is a bit of a glitch with the player for the first few pixels on the LHS.  The write

to GRP0 happens on cycle 27 which is just a bit too late.  I think I need to juggle things

around a bit in the kernel, or learn how to use the VDEL registers properly.  Any

suggestions on how I can tighten the Kernel would also be welcome.

 

Chris

837621[/snapback]

You are storing the player's image data in two spots; the head (unanimated) is in one spot and the body (4-frame animation) is in another spot. I assume you are doing this to save ROM space, but it is complicating your kernel and I don't know if you really saving enough space to make it worthwhile.

 

By not repeating the unchanging head in the data, you are saving 48 bytes, I think (8 head data bytes * 4 frames + 8 body color bytes).

 

But I count at least ~30 bytes of code in your kernel that this somewhat complicated data scheme now requires. Plus 11+ bytes of code to set up a separate pointer for the head data.

 

Now your ROM savings are down to only ~7 bytes, if any! Plus you lose the ability to animate the head, if you decide to in the future, or change colors in the body, if you want to.

 

Plus, of course, it makes your SwitchDraw routine take 27 cycles, which makes it difficult to get the graphics writes in at the appropriate time.

 

I'd suggest putting all the player data in one spot.

 

Good start! I wasted 15+ minutes playing it; fun stuff

[mister_pal]

Great game this one is really fun!

[cd-w]

You are storing the player's image data in two spots; the head (unanimated) is in one spot and the body (4-frame animation) is in another spot.  I assume you are doing this to save ROM space, but it is complicating your kernel and I don't know if you really saving enough space to make it worthwhile.

...

I'd suggest putting all the player data in one spot. 

837668[/snapback]

 

Thanks for the suggestion. I put the player data in one spot and it did indeed save space (and

fix the glitch). I've been optimizing it all weekend and it is now just a few bytes over 1K in size.

I will post an update here once I have workerd out the last remaining issues. I just hope the

minigame competition this year doesn't change the file sizes!

 

Chris

[+batari]

I've been optimizing it all weekend and it is now just a few bytes over 1K in size.   

I will post an update here once I have workerd out the last remaining issues.  I just hope the

minigame competition this year doesn't change the file sizes!

838335[/snapback]

If they keep the file sizes the same, I'll bet that the 2600 entries will dominate the 1k category this year. I just checked the minigame website, and the previous organizer says that he's planning on recruiting a new organizer within a week, so hopefully we'll hear soon if we've been wasting our time doing all this optimization...

[uosipa llamxew]

fun game! The difficulty sure ramps up! I can't get past this room (I think it is 2 rooms after the 3rd vine room?)

 

Phew! Back to the game!

[Gateway]

I like this game.

 

Okay, so attached below shows the farthest I can get( with the vine ). I doubt anybody can get beyond this screen from the current version of the game. I found it to be impassable, due to the timing of the white missle overhead and the speed of the vine will not allow an opportunity to traverse the ravine without getting knocked off by the missle.

 

Also, the controls are really sensitive, especially when ytrying to grab the vine, I often would double-jump instead of staying held to the vine. The only real way to keep your grip is to continually push to the right while swinging, but then you can see I get knocked off by the white missle. If Hunchy could move up or down the vine to avoid the missle, that'd be less frustrating, or change the timing of the missle and vine swinging.

 

In the other picture, you see the 3 pits, with the 3 "enemies" who jump at you in a repeated pattern. I'm not familiar with the original game, so, what are these supposed to be?

 

At first, they looked to me like girls in their blue dresses and yellow boots jumping up to hit you with their umbrellas! LOL!

[uosipa llamxew]

I like this game. 

 

Okay, so attached below shows the farthest I can get( with the vine ). I doubt anybody can get beyond this screen from the current version of the game. I found it to be impassable, due to the timing of the white missle overhead and the speed of the vine will not allow an opportunity to traverse the ravine without getting knocked off by the missle.

 

Also, the controls are really sensitive, especially when ytrying to grab the vine, I often would double-jump instead of staying held to the vine. The only real way to keep your grip is to continually push to the right while swinging, but then you can see I get knocked off by the white missle. If Hunchy could move up or down the vine to avoid the missle, that'd be less frustrating, or change the timing of the missle and vine swinging.

 

In the other picture, you see the 3 pits, with the 3 "enemies" who jump at you in a repeated pattern. I'm not familiar with the original game, so, what are these supposed to be?

 

At first, they looked to me like girls in their blue dresses and yellow boots jumping up to hit you with their umbrellas! LOL!

838561[/snapback]

 

If that is the first vine that has the missile overhead, then it is passable. It took many tries, but you must jump on the vine and jump again quickly to ride underneath the missile to the other side. The screenshot I posted above is one or two screens past that when the bottom missile is going so incredibly fast that you only have a millisecond to reposition yourself for the next jump. If this is not the first vine with the missile overhead then please disregard my post. There's no score or screen number to be sure.

[Gateway]

Yeah, it's the first high missle/vine combo.

 

Arggh!! This current version of the game is frustrating!

 

If your jumps aren't exactly timed, you die, especially on the screens with multiple obstacles. And the vines are near impossible to grip tightly!

 

This reminds me of the PAL game, "Bobby is going Home/Wilma Wanderer/Lilly Adventure", but more difficult.

[+batari]

I've been playing this too - very addicting! I think I'll revise my earlier suggestion about limiting the number of men. Some of the levels are hard, so having infinite men here is really nice. If I had to start over every time I wouldn't have played this as long as I have.

[vdub_bobby]

You are storing the player's image data in two spots; the head (unanimated) is in one spot and the body (4-frame animation) is in another spot.  I assume you are doing this to save ROM space, but it is complicating your kernel and I don't know if you really saving enough space to make it worthwhile.

...

I'd suggest putting all the player data in one spot. 

837668[/snapback]

 

Thanks for the suggestion. I put the player data in one spot and it did indeed save space (and

fix the glitch). I've been optimizing it all weekend and it is now just a few bytes over 1K in size.

I will post an update here once I have workerd out the last remaining issues. I just hope the

minigame competition this year doesn't change the file sizes!

 

Chris

838335[/snapback]

By the way, that was a pretty clever idea - storing the data in two spots. If you had more animation frames it might have been worthwhile - and you probably could have rearranged things in your kernel so all the graphics writes happened in time.

 

In any case, I did enjoy playing it; glad you were able to optimize that much - fun stuff! And I also got stuck on the screen with the two pits, low fast ball and high not-so-fast arrow thing. I spend about 5 minutes trying to figure out some timing for that one and couldn't do it.

[+Andrew Davie]

Firstly, a big congratulations for doing your first game! I really mean that. It's a big step for anyone.

 

I would just like to add a cautionary note, however. As your work is partially derived from the work of others, and some of that work is most definitely NOT released under the GPL license, you cannot blanket-include your source under GPL!

 

Some of that other source is already operating under other licenses, or has been freely released with or without other restrictions! Certainly, the tutorials you have read and the help you may have received from others was given freely and without restriction.

 

The GPL attempts to blanket-override all other licensing. For example, your inclusion of sprite positioning code in your GPL'd code would require all subsequent users of such code to similarly release their code under the GPL! This code may even be copyrighted to someone else anyway! The free sharing of code in the '2600 scene has been routine and implicit. I see the GPL buggering that up.

 

So my question to you is -- what possessed you to release this code under GPL? What does this licensing scheme offer to the community as a whole, other than the inconvenience of forcing all subsequent software released to be also released with a copy of the GPL? Have you fully read the GPL itself? Are you fully aware of the requirements this imposes on subsequent users of your source?!

 

I don't see any advantage for the community in such a move! I say just bang a copyright notice on it if you must. But otherwise, share it freely, just like those from whom you have learned have done. The GPL is a hinderence, not a help.

 

Just my controversial 2c.

 

Cheers

A

[cd-w]

Thanks for all the comments - it's very encouraging to see so many downloads in such a

short time, and hear that people are having fun playing it. I thought I would reply to the

posts in one message rather than individually:

 

1) The level with the vine and the single overhead missile (level 12) can be done by waiting for

the first two missiles to pass, and then catching onto the swinging vine immediately after the

third missile passes overhead. I'm not sure about the level 2 screens after this one (level 14)

as this is one level that I haven't managed to do myself yet. I might need to tweak the timing

on this one a bit.

 

2) I'm not sure why it is difficult to grip onto the vine. You simply need to jump towards the

vine and release the fire button and hunchy will grip automatically?

 

3) The enemies who jump up at you are supposed to be soldiers or guards. The top bit is

supposed to be a helmet, covering their eyes. I admit that graphics are certainly not my

strong point, and I intend to ask the pixel artists around here if they can design some better

sprites!

 

4) It would be great to release a cart containing all the 1K games that have been produced

for the minigame competition this year!

 

5) I hadn't really given the license issue much thought as I tend to release all my code under

GPL. Basically I just wanted the code to be free for people to use in their own projects.

However, the point about the code being derived from other examples is certainly true,

and I will release the next one without any license to be fair to everyone.

 

Chris

[cd-w]

I have attached an updated version of my hunchy game to this message. The key change is

that the game is now 1K in size (ready for the minigame compo). The other changes are:

 

1) The graphical glitches are now mostly fixed (thanks vdub_bobby).

2) The damsel (Esmeralda) is now gone along with the final screen, as it wouldn't fit into 1K.

3) The levels should be a little bit easier to complete, and there is an extra level.

4) The GPL license has been removed

 

Please let me know if you find any glitches or bugs, as the code had to be obfuscated a bit to

fit into 1K. Also, let me know if you have any suggestions for the upcoming 2K "Deluxe" edition.

 

Chris

hunchy02.zip

Edited April 23, 2005 by cd-w

[+batari]

Please let me know if you find any glitches or bugs

842449[/snapback]

I recommend that you (and all other homebrewers) to not use the VERTICAL_SYNC macro in the macro.h file. Recently, the screen rolled in the game "fall down" on real hardware and the problem seems to be with this macro, which looks something like this:

 

MAC VERTICAL_SYNC

lda #%1110 ; each '1' bits generate a VSYNC ON line (bits 1..3)

.VSLP1 sta WSYNC ; 1st '0' bit resets Vsync, 2nd '0' bit exit loop

sta VSYNC

lsr

bne .VSLP1 ; branch until VYSNC has been reset

ENDM

 

This macro was changed from an earlier version because it only uses 9 bytes, but it probably wasn't exhaustively tested. Although nobody is sure of the exact nature of the problem, it may be that it does four writes to VSYNC when the old macro just did two, and my best guess is since VSYNC is asynchronous in the TIA, and the TIA uses very simple latches, a glitch is inadvertantly being sent to the television and causing the vertical sync signal to be corrupted thus the TV loses sync and rolls (I could be wrong on this, but nobody's corrected me yet...)

 

Instead, I recommend that you insert the routine from an older version of macro.h directly into your code. The old macro is known to work, but it does take up more space.

[cd-w]

I recommend that you (and all other homebrewers) to not use the VERTICAL_SYNC macro in the macro.h file.  Recently, the screen rolled in the game "fall down" on real hardware and the problem seems to be with this macro ...

Instead, I recommend that you insert the routine from an older version of macro.h directly into your code.  The old macro is known to work, but it does take up more space.

842458[/snapback]

 

Thanks for the pointer - I will change this in the next release of the code.

I have tried my code on real hardware with my Supercharger and it appears to work.

However, I'm running on PAL hardware and outputting an NTSC picture, so it is probably

not the best test of compatibility. Do you (or anyone else) have a version of the

VERTICAL_SYNC macro which is known to work, as the old versions do not seem to

be available from the DASM page?

 

Chris

[Gateway]

This is from your latest version, how far I can get. The timing on this screen is driving me nuts!

[+Andrew Davie]

Do you (or anyone else) have a version of the

VERTICAL_SYNC macro which is known to work, as the old versions do not seem to

be available from the DASM page?

 

Chris

 

;-------------------------------------------------------------------------------
; VERTICAL_SYNC
; Original author: Manuel Polik
; Inserts the code required for a proper 3 scannline 
; vertical sync sequence
;
; Note: Alters the accumulator
;
; IN:
; OUT: A = 1

           MAC VERTICAL_SYNC
               LDA #$02           ; A = VSYNC enable
               STA WSYNC          ; Finish current line
               STA VSYNC          ; Start vertical sync
               STA WSYNC          ; 1st line vertical sync
               STA WSYNC          ; 2nd line vertical sync
               LSR                ; A = VSYNC disable
               STA WSYNC          ; 3rd line vertical sync
               STA VSYNC          ; Stop vertical sync
           ENDM

[cd-w]

This is from your latest version, how far I can get. The timing on this screen is driving me nuts!   

842712[/snapback]

 

You will be happy to know that this is the very last level of the game! I'm not sure this one is possible as I haven't managed it myself yet ...

[cd-w]

;-------------------------------------------------------------------------------
; VERTICAL_SYNC
; Original author: Manuel Polik
...

842765[/snapback]

 

Thanks - I have attached a new version which uses this routine. There is also a preliminary

50Hz PAL version included in the archive this time.

 

Chris

hunchy03.zip

[DEBRO]

I recommend that you (and all other homebrewers) to not use the VERTICAL_SYNC macro in the macro.h file.  Recently, the screen rolled in the game "fall down" on real hardware and the problem seems to be with this macro

This is true but we haven't found the real problem yet. If the TIA was disabled right after the WSYNC then the problem didn't occur

[+-^CrossBow^-]

I managed to get through all the levels about an hour or so ago. When you get past that screen, it just starts over at the first level again, and you can repeat the entire process.

 

So for the final version where more code can be used, we need more levels, ease the difficulty a tad, and put the final screen back in for a win! Then repeat with added speed...etc...making it impossible!!

 

hehe...

 

This was a lot of fun!