Jump to content
IGNORED

Graxx - room based action adventure in 8K ROM / 16K RAM


mindlord

Recommended Posts

All the art assets are in ROM, I just need to squeeze in some code to make a game of it. I have about 1.5k left to play with and there's some bytes left floating around in the character set that I can squeeze out.

...

 

Have you compressed it to get as much space as possible for programming. If not @Tursi has a compression/decompression routine that could help. If you need it, I will need to look for the thread than contains it. Otherwise, perhaps, @Tursi will chime in.

 

...lee

Link to comment
Share on other sites

I did a few FR99 carts using a standalone version of my VGM compression tools. While it wasn't meant for general purpose compression, it does "ok", and decompression is both fairly fast and does not require additional buffers. It DOES require a fair bit of RAM, but you could backup scratchpad and store its work data there during the decompression, and then restore scratchpad when you're done. If you want that, I can post it, not sure if I ever did.

Link to comment
Share on other sites

Here's some progress on Graxx. Still have a little bit of ROM left, and I've come up with some clever tricks to swap "rooms" of data with the VDP to recover some RAM. I'm not really happy with how the torch makes the darkened rooms flicker, but there's room to improve that. I should stress that the framerate of the video really makes the smoothness of the animations suffer. I'm working on a better capture method.

 

https://youtu.be/dFX4kyevtf8

Edited by mindlord
  • Like 6
Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...

Whoa!!! Progress report? This looks great!!

 

Yeah... It looked like I dropped off the radar there for a minute didn't it?

 

I am currently working on saving and restoring room data to VDP RAM, which mostly consistes of enemy data. I've also been working out enemy AI. Basically the toughest part of programming the game. Collision detection, and making sure things aren't "Out of Bounds" are working really well. I want to make a better maze with sub-areas. I've already decided on the win condition for the game. I've also been working on a printable PDF booklet with art to go along with it that contains back-story and gameplay instructions.

 

I'm starting to run out of ROM space and it's time to start making sacrifices to make it all fit. If I just could figure out how to put all the graphic and map data in one 8K bank and load it into VDP and then jump to the next 8K bank that contains the logic I'd probably be golden. Alas, this voodoo is too much for me to handle right now. I'm studying to be a Linux System Administrator and can't spare the brain cells to learn anything new right now.

 

Enemy types may have to be dialed back, as well as item types.

  • Like 1
Link to comment
Share on other sites

You never stated design goals, so it is hard to offer suggestions. Some thoughts and suggestions as I read the thread:

 

* Why the limitation of running on an unexpanded console? A base system of 32K and single disk storage is not an unreasonable expectation. And if that is unreasonable, might as well throw out all the mega-carts with tons of memory people are developing. Why develop those if everyone making new software targets an unexpanded console? I think it is more unusual now for people to *just* have a console, and easy enough to get some expansion.

 

* Why are you moving the entire 8K around, into VRAM, etc? If you are willing to use bank-switching and have multiple banks, just swap to the bank with map data and load the room the player is entering. Also, IIRC most of the bank-switch carts support more than two banks.

 

* I don't know how you are storing map data, but it seems like your passages and walls are always at least two tiles wide. So work on 16x12 grid instead of 32x24. That will effectively cut your map data size in half.

Link to comment
Share on other sites

* Why the limitation of running on an unexpanded console? A base system of 32K and single disk storage is not an unreasonable expectation. And if that is unreasonable, might as well throw out all the mega-carts with tons of memory people are developing. Why develop those if everyone making new software targets an unexpanded console? I think it is more unusual now for people to *just* have a console, and easy enough to get some expansion.

 

Somewhere, someone said - and I'm paraphrasing - "Sure you can compile something using GCC for an unexpanded TI, but you'll won't be able to do anything really interesting."

I took that as a challenge. Also, call me unusual... but all I have is the FlashROM99, and only that because my brother got it for me as a gift. I'm not a person of means, and I push what I have to it's limits. But the hard answer is, why not make a game that runs on an unexpanded TI? It's fun, it's a challenge - to squeeze every useful byte out of the hardware. Amazingly, I still have quite a few bytes of RAM left, so I can still easily avoid a 32K RAM requirement.

 

 

 

* Why are you moving the entire 8K around, into VRAM, etc? If you are willing to use bank-switching and have multiple banks, just swap to the bank with map data and load the room the player is entering. Also, IIRC most of the bank-switch carts support more than two banks.

Right now, I'm not even doing that. 8K ROM. No bank switch... If I could bank switch, all I would need if for is to bounce up, move all the game's characters, maps, and monster data into the VDP for easy access, and bounce back to the executable code. That would free up enough of the lower 8K rom for me to code the rest of the game unhindered, and I wouldn't have to cut any features - maybe even add a few.

 

 

 

* I don't know how you are storing map data, but it seems like your passages and walls are always at least two tiles wide. So work on 16x12 grid instead of 32x24. That will effectively cut your map data size in half.

Each complete room is stored as a 8 by 6 bitmap, with 12 extra bits for room feature flags. Each room is stored as one 64bit long long INT. Which is conveniently the same size as a normal TI Text Character that I can edit using available tools like Magellan. The rooms are rendered on the fly as the player moves from room to room in a very fast single pass using a super tight edge detection algorithm, and 3x3 character tiles. My current map is 7 rooms wide by 4 rooms high A total of 224 Bytes of ROM. If I could bank switch and store more 64bit long long INTs in the second bank I could have an extremely large map, or at least as big as Legend of Zelda's overworld + Dungeons.

Edited by mindlord
  • Like 2
Link to comment
Share on other sites

  • 2 months later...
  • 1 month later...

After breaking the 8K ROM barrier, there's been some significant improvements to the map features. Stylistically it needs some work, but technologically I'm pretty happy with the direction things are going.

The map is now 2K instead of 512K, but it is almost 4 times larger in scale, and have multiple tile types.

 

https://www.youtube.com/watch?v=hsbV9_Sqiq0&feature=youtu.be

  • Like 6
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...