Maze Demo

[havok1919]

I saw your game takes almost all the RAM. Watch out for stack overflow.

My game takes all the RAM? No, your tile map buffer does!

I generate the maze in a separate 37x25 unsigned char array which wastes almost a kilobyte. I was going to convert it to just use the tile memory directly (that's one reason why I was asking about having 8-bit tiles indices), but then I thought that might just make it more confusing and hurt some of the 'simple' for new programmers... I might take a stab at it and see if there's a decent non-obfusicating way I can do it.

I'll have to try some sound/music too. Maybe I'll do an 'advanced' version and spruce up the graphics and sound and people can look at that after they understand the first one...

Also I implemented support for the SNES pads. Buttons mappings will defaults to SNES, NES being re-mapped on the fly. Would be good to use the button constants in HARDWARE.H if you want your game to work in the next rev without too much changes.

OK, good idea. I don't think I saw a hardware.h in the tutorial project-- maybe it doesn't get included by any of the other files. I've only been browsing what showed up in the 'external dependencies' and 'source files' in the AVR studio 'project' dock bar thingy...

-Clay

[uze6666]

I tried to keep at least 12-13% of free RAM for my Megatris game, since the game's call stack can get deep and the main interrupts needs to push all registers. Taking more than that and the game started to act eerily since the stack started to overwrite some variables. Anyway that would make a a good discussion in the programming forum.

but then I thought that might just make it more confusing and hurt some of the 'simple' for new programmers...

Ahhhh...yeah good point...keep forgetting....

I don't think I saw a hardware.h in the tutorial project-- maybe it doesn't get included by any of the other files.

It's under the header files section AVRStudio. But you're right, it' should normally be included only by the game .C file.

Eventually I'd like to package all the kernel code in a library to have less clutter in the IDE. Next rev...

Maybe I'll do an 'advanced' version and spruce up the graphics and sound and people can look at that after they understand the first one...

Yeah in MAZE II . Though for that one you could have a very simple sound fx when the little guy moves (and perhaps when he escapes)...You can have a look at uzeboxcore.c for a very minimalist way to play a fx.

Cheers,

Uze

[havok1919]

I tried to keep at least 12-13% of free RAM for my Megatris game, since the game's call stack can get deep and the main interrupts needs to push all registers. Taking more than that and the game started to act eerily since the stack started to overwrite some variables. Anyway that would make a a good discussion in the programming forum.

Good idea on the 'new topic for discussion'...

Eventually I'd like to package all the kernel code in a library to have less clutter in the IDE. Next rev...

Yeah... "todo". For me, just one little project that did some basic stuff-- read controls, draw on the screen, play sounds, all in one spot would be a perfect learning example. (Maybe your "tutorial" stuff, bundled with something like 'maze' with sound.) I would say that I spent most of my time looking at video.h and uzeboxVideoEngineCore.s to understand the types and exact functionality of the calls-- but I suspect that a lot of beginners would immediately be stumped by the need to find the header file and/or read assembly. (Initially things like SetFont vs. SetTile were not immediately obvious to me... In a perfect word I supposed we'd have API documentation with little examples. "Next rev".)

Yeah in MAZE II . Though for that one you could have a very simple sound fx when the little guy moves (and perhaps when he escapes)...You can have a look at uzeboxcore.c for a very minimalist way to play a fx.

I was eyeballing TriggerFx earlier... Slipped my mind since I didn't have speakers at the desk! I actually have some more "complex" graphics in the tile map (move the eyes in the direction of travel, post-process the maze and use some "shaded' tiles to give the floor shadows). That actually opens up some nice "complexity" to use (since the player graphic then needs multiple versions to match the background tile shadow). Kind-of a good technique to teach for tile-only games.

Of course a sprite version would be easier at that point, but limited to a less complex maze maybe...

-Clay

[uze6666]

In a perfect word I supposed we'd have API documentation with little examples. "Next rev".)

I agree It's a priority, but has you mentionned...next rev! I need a good documentation generator tool. The only one I know is Javadoc. Doxygen perhaps...

Hey, your next version could have a two players mode...first one who reaches the goal? A win/loose display for each would be nice too.

Uze