OK, time for an update. I've attached a ZIP which contains WOLF3D.HEX and WOLF3D.DAT. You will need to put both on your Gamebuino's SD card. Here is an overview of the new features:
- Levels stream from SD card
- Enemies are spawned and fully functional
- Weapons: knife, pistol and machine gun
- Items: ammo, health, machine gun
- Secret push walls
- Menu system with multiple skill levels
- Sound effects based on the PC speaker versions of Wolfenstein 3D sounds
I would attach a GIF like last time, but I haven't yet figure out how to make a .IMG file for Simbuino so that I can emulate the SD card
jonnection wrote:@jhhoward: nice going, you have some serious skills. If I understood correctly, you have been coding Uzebox games.
I'd like to know what kind of environment you develop in. Is it Atmel Studio and if so, are you using a hardware debugger ?
Some experiences of trying to jam the Operation Fox code into 30k:
There is some memory waste in the Gamebuino lib and you should consider what features to use from it. For example, the font character tables in Gamebuino contain the ASCII escape characters although there is no use for them. Leaving out Print functions or strictly using just one type of Print by typecasting as well as using a CAPS ONLY char set can save program memory. Using more than 1 font size is a no-no.
Second, in real hardware you will quickly realize that in fast moving images, the quality of animation is not so critical, because motion blur due to LCD persistence kind of "spoils it" in any case. Looking at your bitmaps on your Github repo, I'd recommend simplifying characters and animations to save memory.
Third, adding streaming from SD is a double-edged thing. On the other hand, you can stream maps from SD. But on the other hand, petitFS will chomp around 3-4k of your precious program memory + RAM overhead. If you're not yet already using PetitFS, you will need to tighten your code quite a bit to make room for PetitFs. Also, my Operation Fox project got burned by the slow seek speed of the 256mb microSD cards that ship with the Gamebuinos. Streaming from SD worked well in my 2GB "Fakebuino" but didn't work at all for people who were playing on a real Gamebuino.
Fourth, re-use functions as much as possible. For example, I had a bitmap overlay function (simple OR to screenbuffer) and an alpha-channeled bitmap function. By replacing all OR overlay functions with calling the same alphabitmap function with the bitmap itself as mask, I got the same result with 1 function only and no noticeable speed hit. But you are clearly an experienced programmer, so you know this stuff.
Really looking forward to your next version !
Sorry for the late reply, but better late than never! You are correct that I have also made some Uzebox games before. I made the GTA style game 'Joyrider' for the coding competition last year. When developing Wolfenduino I had it in mind that I could potentially have a Uzebox port as the architectures are so similar. However it looks like it would need a major rethink as the Gamebuino has far more CPU cycles to spare than the Uzebox. (Uzebox is clocked higher but spends most of its time generating a video signal)
I've been developing this game in Visual Studio, and I have a version that runs in Windows using SDL. Running on desktop, I can make quick iterations and debug the game logic very easily. I then have a really simple script that generates an Arduino sketch which lets me test it on the actual Gamebuino hardware.
I used some of your tips about fitting things into program memory: I slimmed down the Gamebuino library to only the most basic requirements and I created my own font and text rendering that uses less characters and less space. It has been a constant struggle to squeeze everything in!
I've been having some issues with the SD card streaming: it works for the most part, but occasionally I have a strange problem where the wrong data is loaded. I'm not sure if it is a hardware issue (i.e. my SD card or Gamebuino) or a bug in the Petit Fatfs implementation. As you move around the level, it is streamed in 'strips'. For example, if you move one tile south, a strip of 16 tiles is loaded in a horizontal pattern, in a single read. Occasionally, incorrect data is loaded and I'm not sure why. The strange thing is:
- It isn't garbage, the data loaded looks to be from elsewhere in the map
- It isn't left over from the last read, I've tried clearing the buffer
- No errors are being reported from the Petit Fatfs library
- If I seek, then load one byte at a time, then the problem still occurs
- If I seek and load for each byte (which is terribly slow) the problem disappears
It leads me to suspect either
a) It is a hardware timing problem, and performing the seek is masking the problem as it is so slow?
b) There is a bug in the seek function?