nesdev.org

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

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

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!

Dwedit wrote:

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

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

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.

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.
.
Gotta love how this is the first time I ever use DirectDraw, then Microsoft goes and deprecates it several years ago.

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?

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.

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

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.

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

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.

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.

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

SO. PRETTY. Wow this really makes me want to do a game with different screens so I can make pretty graphics, too!


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