Working on a new game for that compo

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Working on a new game for that compo

Post by Dwedit » Wed Aug 04, 2010 11:48 pm

Image

So far, I have some code written for updating rows of the nametable, and writing it to the PPU, so that's all there's a screenshot of. It should be doing 4-way scrolling later. I don't have the code for assigning the attribute tables in yet, so it's all palette #0, the gray palette.

It will be an adventure game on a bunch of large sprawling maps, and it's targeting the minigame size of 16k + 8k CHR ROM.

Giant 8x8 metatiles (of 16x16 tiles) and RLE for picking the metatiles will makes things really big at a really small size. Hope you don't mind repetition :)
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Thu Aug 05, 2010 12:06 am

Really nice! This is in the Minigame category? Oh snap....I'll never win crap from any compo but what the heck it'll be fun :P

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Fri Aug 06, 2010 12:55 am

Image
Let there be color!

Got the attribute tables working. Bugs in the interim version of FCEUX misled me to believe there were strange bugs in my code.

Now to test the attribute tables code for drawing column-by-column instead of row-by-row. (edit: done, column-by-column updates fine too)

Then later...scrolling!
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

reverse squiggly

Post by tepples » Fri Aug 06, 2010 5:03 am

Dwedit wrote:Image
Nice reverse squiggly blocks. Do you plan on having screens with the other Tetris blocks on them?

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Sun Aug 08, 2010 3:55 am

Image

And now it scrolls freely in 4 directions, and I managed to squash LOTS and lots of bugs in the process.

Play with the scroller demo
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
Gil-Galad
Posts: 321
Joined: Sat Nov 13, 2004 9:43 pm
Location: Ohio, USA
Contact:

Post by Gil-Galad » Sun Aug 08, 2010 4:14 am

That looks pretty neat and a good start. I assume that you work on scrolling first before adding a sprite character and collision detection?

I don't know since I haven't made a game before.

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Sun Aug 08, 2010 4:40 am

When I did Chu Chu Rocket, the first thing programmed for the NES was the code that moves the mice forward. (basically moving an array forward in memory), but there was tons of planning before anything got written, mostly to figure out how to animate all possibilities of moving mice with a limit of 512 tiles.

For this game, I wrote the background rendering and scrolling system first. Now when I make the game logic, I just change the camera coordinates, call a function, and it scrolls somewhere else, and the new rows and columns get drawn at the next NMI. It will screw up if it tries to scroll more than 8 pixels though.

Also, long before I wrote any NES code for this game, I made this thing:
Still unfinished, no sprites there either.
Image.
Gotta love how this is the first time I ever use DirectDraw, then Microsoft goes and deprecates it several years ago.

User avatar
Gil-Galad
Posts: 321
Joined: Sat Nov 13, 2004 9:43 pm
Location: Ohio, USA
Contact:

Post by Gil-Galad » Sun Aug 08, 2010 6:05 am

That's interesting how you're designing this game. Let me know how it turns out. Also, are you planning on adding a music driver?

drHirudo
Posts: 8
Joined: Tue Jan 04, 2005 3:07 am
Location: Sofia
Contact:

Re: Working on a new game for that compo

Post by drHirudo » Sun Aug 15, 2010 10:51 am

Looks very interesting. What tools/assembler/SDK are you using for creating of the game? Are you going to release the sourcecode? Do you plan to use some kind of compression (For the graphic tiles it will work very good) or you will put the raw data in the ROM?

16KB shall be enough, but if you compress everything, you will have much more free space for Title Screens, Intro, Tutorial, Manual and most importantly - Music.

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sun Aug 15, 2010 1:46 pm

For the minigame competition, compression for graphic tiles would actually reduce the amount of space for everything else because the rules give you a "free" 8 KiB CHR ROM, and CHR ROM can't be compressed.

(Full disclosure: There is one situation in which this might not be the case, involving a game that only uses half its PRG ROM. A game with a 9 KiB PRG and a 10 KiB CHR that compresses to 7 KiB would work better with CHR RAM. Concentration Room might have been like this at one point in its conception.)
Last edited by tepples on Sun Aug 15, 2010 2:13 pm, edited 1 time in total.

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Sun Aug 15, 2010 1:59 pm

Using ASM6 to build the game. Using YY-CHR and Photoimpact to do the graphics. Using various other custom tools as needed.

Unless Jeoren changes the rules, I can use 8KB of CHR-ROM with any graphics in addition to the 16k of PRG ROM, no data allowed in CHR-ROM, and I can NOT use an 8k WRAM chip.

With CHR-ROM being static, I won't use any graphics compression.

Level data will be compressed to hell.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

WJYkK
Posts: 60
Joined: Thu Dec 24, 2009 12:23 am
Location: Igloo and Bear Land (Canada)
Contact:

Post by WJYkK » Mon Aug 16, 2010 1:10 am

Dwedit wrote:Level data will be compressed to hell.
Try to compress the data in a "block X spans an area of Y by Z blocks".

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Aug 16, 2010 2:48 am

The kind of compression I'm using:
Big 8x8 blocks of 16x16 tiles, then the map that uses them is RLE compressed. Each 8x8 block is 4 bits per tile, for 32 bytes per block, packed but not compressed, so there's random access to the tiles. 256 of those would be 8K in size.

I was also thinking of possibly compressing the blocks instead of just packing them, would need some RAM to hold the decompressed blocks, I have 768 bytes that I haven't reserved yet, so that could be 24 blocks per area. In order to have any benefit, the blocks would need to be significantly less than 32 bytes each.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Oct 25, 2010 3:29 pm

Image
With enemies placed on the map now. They don't do anything yet.
Black bar on left is a crude CPU usage counter that turns off sprites and backgrounds for the left 8 pixels before calling WaitFrame.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Mon Oct 25, 2010 6:06 pm

Dwedit wrote:Image
With enemies placed on the map now. They don't do anything yet.
Black bar on left is a crude CPU usage counter that turns off sprites and backgrounds for the left 8 pixels before calling WaitFrame.
:shock: SO. PRETTY. :D Wow this really makes me want to do a game with different screens so I can make pretty graphics, too! :cry:


Dang man.....this looks like RetroUSB future stock, hopefully! :D

Post Reply