Jump to content

Photo

Hunchy (my first 2600 homebrew game)


82 replies to this topic

#1 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Fri Apr 15, 2005 4:00 AM

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?
Posted Image

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.

Attached Files


Edited by cd-w, Fri May 20, 2005 2:51 PM.


#2 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,645 posts
  • begin 644 contest

Posted Fri Apr 15, 2005 5:28 AM

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.

#3 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,645 posts
  • begin 644 contest

Posted Fri Apr 15, 2005 5:55 AM

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.)

#4 cd-w OFFLINE  

cd-w

    Stargunner

  • Topic Starter
  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Fri Apr 15, 2005 7:28 AM

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.)

View Post


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

#5 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,831 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Fri Apr 15, 2005 9:41 AM

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

View Post

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! :thumbsup: I wasted 15+ minutes playing it; fun stuff ;)

#6 mister_pal OFFLINE  

mister_pal

    Moonsweeper

  • 269 posts
  • Location:Edmonton, Canada

Posted Sat Apr 16, 2005 1:36 PM

Great game this one is really fun!

#7 cd-w OFFLINE  

cd-w

    Stargunner

  • Topic Starter
  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sat Apr 16, 2005 2:06 PM

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.  :)

View Post


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

#8 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,645 posts
  • begin 644 contest

Posted Sat Apr 16, 2005 4:58 PM

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!

View Post

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...

#9 mojofltr OFFLINE  

mojofltr

    River Patroller

  • 2,600 posts

Posted Sat Apr 16, 2005 6:42 PM

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! :D

#10 Gateway OFFLINE  

Gateway

    River Patroller

  • 2,165 posts
  • Trotter Atari Globetrotter now on Facebook!
  • Location:St. Joseph area, Missouri

Posted Sat Apr 16, 2005 10:16 PM

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!

Attached Thumbnails

  • hunchy1.jpg
  • hunchy2.jpg


#11 mojofltr OFFLINE  

mojofltr

    River Patroller

  • 2,600 posts

Posted Sat Apr 16, 2005 10:52 PM

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!

View Post


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. :D

#12 Gateway OFFLINE  

Gateway

    River Patroller

  • 2,165 posts
  • Trotter Atari Globetrotter now on Facebook!
  • Location:St. Joseph area, Missouri

Posted Sun Apr 17, 2005 12:06 AM

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

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

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. :|

#13 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,645 posts
  • begin 644 contest

Posted Sun Apr 17, 2005 12:28 AM

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.

#14 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,831 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Sun Apr 17, 2005 1:14 AM

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.  :)

View Post


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

View Post

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. :)

#15 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,741 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sun Apr 17, 2005 5:59 AM

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

#16 cd-w OFFLINE  

cd-w

    Stargunner

  • Topic Starter
  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sun Apr 17, 2005 2:41 PM

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

#17 cd-w OFFLINE  

cd-w

    Stargunner

  • Topic Starter
  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sat Apr 23, 2005 3:40 AM

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

Attached Files


Edited by cd-w, Sat Apr 23, 2005 3:41 AM.


#18 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,645 posts
  • begin 644 contest

Posted Sat Apr 23, 2005 5:16 AM

Please let me know if you find any glitches or bugs

View Post

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.

#19 cd-w OFFLINE  

cd-w

    Stargunner

  • Topic Starter
  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sat Apr 23, 2005 11:05 AM

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.

View Post


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

#20 Gateway OFFLINE  

Gateway

    River Patroller

  • 2,165 posts
  • Trotter Atari Globetrotter now on Facebook!
  • Location:St. Joseph area, Missouri

Posted Sat Apr 23, 2005 6:22 PM

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

Attached Thumbnails

  • HUNCH1K01.jpg


#21 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,741 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sat Apr 23, 2005 8:44 PM

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



#22 cd-w OFFLINE  

cd-w

    Stargunner

  • Topic Starter
  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sat Apr 23, 2005 9:58 PM

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

View Post


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 ...

#23 cd-w OFFLINE  

cd-w

    Stargunner

  • Topic Starter
  • 1,446 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sun Apr 24, 2005 3:28 PM

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

View Post


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

Attached Files



#24 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,911 posts
  • Location:Atlanta, GA

Posted Mon Apr 25, 2005 8:29 AM

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 :?

#25 -^CrožBow^- OFFLINE  

-^CrožBow^-

    River Patroller

  • 4,498 posts
  • Collector of Fine Atari and Sega Antiquities!
  • Location:Ivory Tower, Fantasia (Oklahoma)

Posted Mon Apr 25, 2005 4:50 PM

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!




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users