Pogo Cats - NESdev BBS

Pogo Cats
by Yggi on 2012-03-04 (#90875)

Hi.
I'm proud to present you my new game. I hope you like it.

The gameplay is very simple. You need to jump to upper platforms. Each pixel scrolling will give you 1 point. If you fall down the screen, you'll loose. The goal is to make as many points as possible.
Here is the meaning of the different Items/Objects:
Spring coil: Jumping with the spring coil will give you about 400 points
Coin: Gives 500 points
Flying Heart: If you collect this item, your jump speed and jump size will get increased for a short time.
Tornado: If you come to close to it, it will blow you away. Jumping onto a tornado will make you jump several screens high (gives about 1000 points)
Black Hole: If you come to close to it, it will suck you inside. If you touch it, you will loose lots of points.

There are two versions available. One simple NROM128 version, which saves the highscore to NES RAM and one NROM128 with battery-backed PRG RAM, which saves the highscore there (so the highscore will stay available).

with battery

without battery

Could somebody try this on the real NES?

Edit 20.03.2012:
I changed the mirroring to vertical mirroring for tepples' multicart (the gameplay is still excatly the same. The only change is that the nametable is switched after sprite 0 hit). I also fixed a bug in the background scrolling.

Edit 21.05.2012:
Fixed a bug which caused the game to crash when attempting the highest score possible.

by Shiru on 2012-03-04 (#90877)

Nice little game. The only major problem for me is how the music sounds, it almost hurts.

by Yggi on 2012-03-04 (#90878)

Shiru wrote:
Nice little game. The only major problem for me is how the music sounds, it almost hurts.

hm yes, the music is not very well. It was the first time, that i did sound programming (btw thanks to metalslime for his nerdy nights sound tutorials) and also the first time that i actually made nes music. But I'm not very good in music anyway.

by 3gengames on 2012-03-04 (#90879)

I like the music, it just seems a little rough. Good game though! I enjoy it, it's a great first attempt.

Re: Pogo Cats
by infiniteneslives on 2012-03-04 (#90880)

Yggi wrote:
There are two versions available. One simple NROM128 version, which saves the highscore to NES RAM and one NROM128 with battery-backed PRG RAM, which saves the highscore there (so the highscore will stay available).

with battery

without battery

Could somebody try this on the real NES?

What's the 0x01 in the 8th byte of the header doing there? From what I understand that doesn't follow the ines file header requirements. But that doesn't matter much to me. For me to test it out with the NESDEV1 I just need to understand your hardware configuration. So the battery backed version is just 8KB of battery backed WRAM sitting at it's normal location right? I just wanted to make sure because the header didn't make sense to me. I'll try it out this evening assuming it's as simple as it sounds.

by tepples on 2012-03-04 (#90882)

I couldn't figure out the hit boxes for reliably collecting coins and winged hearts. Otherwise, it looks like it has potential.

by Yggi on 2012-03-04 (#90885)

3gengames wrote:
I like the music, it just seems a little rough. Good game though! I enjoy it, it's a great first attempt.

Thanks

infiniteneslives wrote:
What's the 0x01 in the 8th byte of the header doing there? From what I understand that doesn't follow the ines file header requirements.

According to the wiki byte 8 specifies the the size of prg ram n 8kb units. That's the reason why I set it. But I'm not sure, if I did unterstand that correctly...
But I just found out, that setting this byte is not really needed if the sram flag (bit 1) in byte 6 is set, because 8kb is assigned automatically.

infiniteneslives wrote:
For me to test it out with the NESDEV1 I just need to understand your hardware configuration. So the battery backed version is just 8KB of battery backed WRAM sitting at it's normal location right?

yes, $6000-$7FFF, but I just need a few bytes...

infiniteneslives wrote:
I'll try it out this evening assuming it's as simple as it sounds.

That would be great

tepples wrote:
I couldn't figure out the hit boxes for reliably collecting coins and winged hearts. Otherwise, it looks like it has potential.

Thanks. You need to jump on them with the bottom part of the pogo stick, like on platforms. Collecting them normally by bounding box collision like in SMB would make this game to easy.

by infiniteneslives on 2012-03-04 (#90887)

Yggi wrote:
According to the wiki byte 8 specifies the the size of prg ram n 8kb units. That's the reason why I set it. But I'm not sure, if I did unterstand that correctly...
But I just found out, that setting this byte is not really needed if the sram flag (bit 1) in byte 6 is set, because 8kb is assigned automatically.

Yeah I guess I was just going off the docs on the homepage which say they NEED to be 0x00. I don't think it matters though really. I'll get it configured up and report back this evening. I actually kind of needed something like this to verify that the WRAM battery backing worked. And since I haven't got the MMC1 working yet I couldn't use original roms to test this. So this will work great!

by Banshaku on 2012-03-04 (#90903)

Good to see a new game. I didn't have the time to try it yet (I don't have access to an emulator right now) but by the explanation, the game is a doodle jump clone, am I correct? Sounds like that to me.

by miker00lz on 2012-03-04 (#90909)

it's a fun game, but after a few minutes it gets a little repetitive. i played up to about 35k points (after a few attempts). it's a good game though especially for a first attempt. much better than anything i could do. i feel like it would benefit from some sort of extra gameplay mechanic or something though. what that would be, i don't know.

by infiniteneslives on 2012-03-05 (#90921)

So I tried to test things out on the NES. I didn't have much luck though. Unfortunately I can't be sure that my WRAM control logic is proper because I've never tested this configuration before. But I do know the physical chip and pcb traces are good because I've played NROM games with my WRAM memory wired up as PRG ROM.

Here's my wram signals in verilog:
Code:
            w_ce = ~(b_prg_ce & b_prg_addr[14] & b_prg_addr[13] & b_m2);    //wram /CE signal
            w_oe = 1'b0;    //wram /OE signal
            w_we = b_prg_rw;    //wram /WE signal

What I see is basically the same thing you see in FCEUX. the block below high score is blue with black cross hatches. When I play in nestopia everything works as I guess you're hoping seeing the value for the highscore.

I'm not sure if fceux doesn't recognize the wram in mapper 0 but I would think that it does. Also for what it's worth I didn't put any logic in for what your header was, I just used the code above for all times in mapper 0. So I'm not sure fceux is more accurate here and that's why I'm seeing the same this as it or if it's just a coincidence and we're both broken.

Let me know if you've got another build or something else you'd like me to test. BTW do the powerpak mappers support WRAM in mapper 0? If so I'm sure someone could test to see if they have the same issue or not.

by Bregalad on 2012-03-05 (#90934)

Quote:
the game is a doodle jump clone, am I correct?

Yes it's exactly that.

It's good to see so many new homebrews released for the NES ! This one is good but there is something wrong with the pitch of the notes I think. You should probably re-compute the pitch table if you're ever writing a revision of the game.

No offense, but I think it's silly to use batteries to save high score. The NES standard is that either you have a lot of data to save, then you use battery, either you don't and you use passwords, and if you just have highscores, the standard is to init them to 5000 (or another value, it doesn't matter), and then have them reset-presistant so that the high scores are preserved when you reset the game, but lost when you turn it off.

by Yggi on 2012-03-05 (#90948)

infiniteneslives wrote:
What I see is basically the same thing you see in FCEUX. the block below high score is blue with black cross hatches. When I play in nestopia everything works as I guess you're hoping seeing the value for the highscore.

I'm not sure if fceux doesn't recognize the wram in mapper 0 but I would think that it does. Also for what it's worth I didn't put any logic in for what your header was, I just used the code above for all times in mapper 0. So I'm not sure fceux is more accurate here and that's why I'm seeing the same this as it or if it's just a coincidence and we're both broken.

Not sure if I did unterstand you correctly (my english is bad). Do you mean there is a visible glitch inside the main screen? If so, could you tell where exactly this happens? I didn't have any problems with fceux .

miker00lz wrote:
it's a fun game, but after a few minutes it gets a little repetitive

Thanks for the feedback. Maybe it's a bit too easy... But for this game, I'm happy with it.

Banshaku wrote:
the game is a doodle jump clone, am I correct?

Yes. Doodle Jump was my main inspiration

Bregalad wrote:
This one is good but there is something wrong with the pitch of the notes I think. You should probably re-compute the pitch table

It sounds a bit outta tune.. I need to fix that. I need to look for a better note table.

Bregalad wrote:
No offense, but I think it's silly to use batteries to save high score. The NES standard is that either you have a lot of data to save, then you use battery, either you don't and you use passwords, and if you just have highscores, the standard is to init them to 5000 (or another value, it doesn't matter), and then have them reset-presistant so that the high scores are preserved when you reset the game, but lost when you turn it off.

The battery-version is just for emulator-users to avoid the use of save states. If I'll do a cartidge version I would probably make just a simple NROM-cart.

by infiniteneslives on 2012-03-05 (#90949)

Yggi wrote:
infiniteneslives wrote:
What I see is basically the same thing you see in FCEUX. the block below high score is blue with black cross hatches. When I play in nestopia everything works as I guess you're hoping seeing the value for the highscore.

I'm not sure if fceux doesn't recognize the wram in mapper 0 but I would think that it does. Also for what it's worth I didn't put any logic in for what your header was, I just used the code above for all times in mapper 0. So I'm not sure fceux is more accurate here and that's why I'm seeing the same this as it or if it's just a coincidence and we're both broken.

Not sure if I did unterstand you correctly (my english is bad). Do you mean there is a visible glitch inside the main screen? If so, could you tell where exactly this happens? I didn't have any problems with fceux.

This is what it looks like everytime I die on FCEUX and the NES as well. It's not an issue of things being saved after power down, it's an issue of not being able to get them to save in the first place. When I play the non-battery version it works fine on both the NES and FCEUX. I'm Thinking it might be an issue of the RAM initialization data. Nestopia assumes one thing and FCEUX and I initialize differently?

Quote:
No offense, but I think it's silly to use batteries to save high score.

You realize he made a version that doesn't save right? So if you don't like the save feature he implemented than you can use the standard one. The other thing is the real point of playing this game is to get a high score, not an adventure killing off baddies and getting points you don't care about in the process. So to me it makes sense if you really enjoyed playing the game to somehow be able to permanently save your high score. Who cares if you "waste" data space or 8KB of WRAM and battery to do it, it's your CHOICE to use them or not. I for one am very happy you chose to implement this option because it gives me a chance to test some things out on my hardware.

Also as far as the game goes I wanted to say it looks really good and clean I like the graphics and artwork. I also like the mechanics and physics of the game especially those tornadoes! It was also a nice touch to have the background move up and down when they jump and land it has a nice way of giving the illusion of jumping. Great job!

by Bregalad on 2012-03-05 (#90951)

Quote:
It was also a nice touch to have the background move up and down when they jump and land it has a nice way of giving the illusion of jumping

Yeah. I'm impressed at how it did that, it looks like the background scrolled when it didn't, or just by a few pixels. Nice effect !

And I did not realize the save version was wrong, I was just pointing out the very idea of using battery just for high score is silly (so I of course tried the normal version).

by Yggi on 2012-03-05 (#90965)

infiniteneslives wrote:
Also as far as the game goes I wanted to say it looks really good and clean I like the graphics and artwork. I also like the mechanics and physics of the game especially those tornadoes! It was also a nice touch to have the background move up and down when they jump and land it has a nice way of giving the illusion of jumping. Great job!

Thanks a lot!

infiniteneslives wrote:
This is what it looks like everytime I die on FCEUX and the NES as well. It's not an issue of things being saved after power down, it's an issue of not being able to get them to save in the first place. When I play the non-battery version it works fine on both the NES and FCEUX. I'm Thinking it might be an issue of the RAM initialization data. Nestopia assumes one thing and FCEUX and I initialize differently?!

It works with the newer FCEUX 2.1.5 - also with the older FCEUXDSP. But not with 2.1.4a for some strange reason. I couldn't find a detailed changelog for 2.1.4a>2.1.5 so I did a lot of testing. I looked inside the hex editor of FCEUX 2.1.4a during runtime and saw that the PRGRAM location is changing the bytes in a constant interval (but only if you do something inside the endless loop, e.g. loading a byte into the accumulator). I wonder why. It does the same when PRGRAM bit is not set, so I assume it just ignores the wram bit at byte 6 for the NROM mapper while the new version accepts it? But what is the PRGRAM location used for if there is no PRGRAM? I didn't found any info on this.
For example, taking this very simple example:

Code:
.db "NES", $1A
.db $01, $01, %00000010
.db $00, $00, $00
.db $00, $00, $00
.db $00, $00, $00

.org $C000

NMI:
RTI
RESET:
SEI
CLD
LDX #$FF
TXS

PPUWarmup1:
LDA $2002
BPL PPUWarmup1
PPUWarmup2:
LDA $2002
BPL PPUWarmup2

LDA #$50
STA $6000
STA $7000

FOREVER:
LDA #$01
JMP FOREVER

.org $FFFA
.dw NMI, RESET, 0

.base $0000
.dsb $2000, $00

In this simple case all bytes in PRGRAM switches repeatedly from value $01 to value $C0. In version 2.1.5 it saves $50 in $6000 but not in $7000 (so i would assume that it does only reserve 4kb). My game needs only a couple of bytes in $6000 so that's the reason why it works with 2.1.5. In FCEUXDSP and Nintendulator this works as expected.

by tepples on 2012-03-05 (#90968)

I'm guessing that because most mapper 0 boards didn't have PRG RAM at $6000-$7FFF, the emulator should emulate open bus at $6000-$7FFF. Family BASIC is a mapper 0 game with PRG RAM there, but its PRG RAM is smaller than 8 KiB, so that might be what you're seeing. If you want to force a particular PRG RAM size, use an NES 2.0 header.

Anyway, you can't count on an emulator or even the actual hardware to initialize RAM to $00, $FF, or any other known value when creating the .sav file. You have to detect whether the RAM has already been "formatted", such as by putting "POGO" in some known location. Actual NES and Super NES games with battery-backed RAM tend to have either a menu (e.g. The Legend of Zelda or Super Mario World) or a hidden button combination (e.g. Super Mario Kart) to erase all data, and they also have a checksum mechanism to verify data.

by Yggi on 2012-03-05 (#90976)

tepples wrote:
Anyway, you can't count on an emulator or even the actual hardware to initialize RAM to $00, $FF, or any other known value when creating the .sav file. You have to detect whether the RAM has already been "formatted", such as by putting "POGO" in some known location. Actual NES and Super NES games with battery-backed RAM tend to have either a menu (e.g. The Legend of Zelda or Super Mario World) or a hidden button combination (e.g. Super Mario Kart) to erase all data, and they also have a checksum mechanism to verify data.

Yes I already had implemented that (only in the battery-version) by using "CAT" string before the highscore. However I did this check only at startup (clear whole RAM if there is no "CAT" and keep it, if there is) - not during the game (like in this case where the data should be drawn).

by infiniteneslives on 2012-03-13 (#91315)

Good news. Something dawned on me today about my hardware setup. I had my prg-data buffer direction wrong because I wasn't considering when the wram was addressed. So all reads from wram came back open bus even though you were able to write to it.

Fixed up my code and everything worked great! Things looked proper when playing the first power up and everything saved after power down as well.

by Yggi on 2012-03-15 (#91354)

infiniteneslives wrote:
Good news. Something dawned on me today about my hardware setup. I had my prg-data buffer direction wrong because I wasn't considering when the wram was addressed. So all reads from wram came back open bus even though you were able to write to it.

Fixed up my code and everything worked great! Things looked proper when playing the first power up and everything saved after power down as well.

Congratulation on that To bad, that some emulators (notably FCEUX) don't allow PRGRAM with mapper 0. Is there any reason why they don't allow it even if the PRGRAM bit is set?

So everything works perfectly on the real NES? I'm very happy about that I was a bit worried about the scrolling....

by infiniteneslives on 2012-03-15 (#91356)

Yggi wrote:
So everything works perfectly on the real NES? I'm very happy about that I was a bit worried about the scrolling....

Yeah it works great. It actually looks and sounds a lot better than in emulators too. I saw some people make comments about something wrong with the sound and I agreed with them when I played in an emulator. But when I played on the NES nothing seemed wrong and the music seemed fitting to me at least.

As you would expect the colors looked better as well.

The scrolling seemed jittery at times on the emu (maybe just my computer) but it was nice and smooth on the NES.

by Yggi on 2012-03-15 (#91363)

infiniteneslives wrote:
Yggi wrote:
So everything works perfectly on the real NES? I'm very happy about that I was a bit worried about the scrolling....

Yeah it works great. It actually looks and sounds a lot better than in emulators too. I saw some people make comments about something wrong with the sound and I agreed with them when I played in an emulator. But when I played on the NES nothing seemed wrong and the music seemed fitting to me at least.

As you would expect the colors looked better as well.

The scrolling seemed jittery at times on the emu (maybe just my computer) but it was nice and smooth on the NES.

That are awesome news
Now I really can't wait to test it myself on real hardware.

About the music, I'm really glad. 'm actually using Celius' (ntsc) notes table. But that should be pretty accurate since i guess a lot of people (including metalslime from nerdy nights sound where i got it) use it.

by tepples on 2012-05-19 (#94116)

Today I beat 33000 for the first time while playing Pogo Cats in Action 53 in in FCE Ultra GX on a homebrewed Wii console. Does it go to 65535, 99999, or what?

by Yggi on 2012-05-21 (#94207)

tepples wrote:
Today I beat 33000 for the first time while playing Pogo Cats in Action 53 in in FCE Ultra GX on a homebrewed Wii console. Does it go to 65535, 99999, or what?

It supposed to go to 9'999'999'999 (and then keeping this maximum), but unfortunately the current version has a bug (which was introduced after some quick changes I needed to make), which caused the game to hang when the points where in the near of the max.
But it was easy to fix. I will upload the new version(s) and update the first post.
However, I doubt that somebody will reach it without cheating (i guess it would take days to reach it)

by tepples on 2012-05-21 (#94208)

Yggi wrote:
However, I doubt that somebody will reach [scores in the billions] without cheating (i guess it would take days to reach it)

Yeah, that was another problem my cousin noticed. It didn't get any harder over time, unlike MineShaft which scrolls faster.

by Yggi on 2012-05-22 (#94249)

tepples wrote:
Yggi wrote:
However, I doubt that somebody will reach [scores in the billions] without cheating (i guess it would take days to reach it)

Yeah, that was another problem my cousin noticed. It didn't get any harder over time, unlike MineShaft which scrolls faster.

I agree, that the game should had atleast a increassing difficulty (maybe by decreasing distance tolerance to next platforms would have been a good idea). I should have done more with the game, even include more 'levels' with themes with their own theme-related difficulty (like winter/ice world with slipping, desert world with constant winds and water world with a higher jump acceleration).
Now that I'm thinking about it... The level-switch could have been done fluently by slowly increasing the distance to the 'background ground' until only the moon would have been visible. Then uploading the nametable of the next theme and slowly scrolling back to the optimal position each time the player is falling.
But anyway, I consider this game as finished now... I'm already working on a bigger and more interesting game

Re:
by tepples on 2016-01-28 (#163365)

Yggi wrote:
But anyway, I consider this game as finished now

Source release plz? Because today in #nesdev, fys, DarkAries, and darryl.revok decided they want Arkanoid controller support in Pogo Cats. I have the controller, the PowerPak, and a test ROM incorporating an Arkanoid controller driver.