WIP: Shadowgate

[uze6666]

The main reason I think SPI ram is required, or at least would be much easier, is because these are not static screens. There are color changes(easy for SD too), but more importantly there are all kinds of objects you can take 1 at a time, doors that open/close, enemies that pop up on the screen, and animated sliding/moving things(appears to be 8px movements). There is also the "tile out/tile in" effects used constantly through the game.

That complexifies things quite a bit. Plain SD streaming seems out of the question.

[D3thAdd3r]

I opened the rom up in Tile Layer Pro and it seems they store the backgrounds and objects as separate graphics, which makes sense. With the SPI ram way I'm assuming you would basically load up the background without items or movable things, in 3 locations. Then load up all the graphics for the different interactive objects somewhere else in SPI ram, and finally store a composite background with the items drawn over the top that you actually show. When the state changes draw all the objects onto the other raw background, flip to displaying it, and copy the raw data from the third back over the 1st. Basically double buffers, with a 3rd buffer that's always just the back ground so you don't have to keep grabbing it from the SD card.

For the SD approach I thought a bit more about it. I don't have a very good idea how many variables are on some of the screens through out the game. Otherwise you could add up the "bits" and see how many screens it would take. Probably would need to eliminate animated things(maybe they aren't that critical), and the tile fade in/out would need to be replaced with simply FadeIn()/FadeOut(), nothing else seems practical for that. For the game logic you might have the screens as n-bit states, where you load up all the object data into ram and depending on their position/state/etc add to the screen binary state, then load the appropriate SD state when ever the screen state changes. A more thorough study would need to be done before committing the time to such a mode, since even a couple unforeseen complications could really create a headache or make it unusable.

[Flecko]

Uze: If you haven't played Shadowgate, stop what you're doing right now and play it. Amazing game, amazing soundtrack.

I'd love to see this work on the Uzebox, but man does it sound ambitious ;P

[uberlinuxguy]

I still have not wrapped my brain around the video mode is going to work, still need to look into D3thAdd3r's suggestions a bit more.

As for the logic, I do like the bitmask per room idea, but it will be a lot of variables to try to keep track of.

It does indeed seem like a pretty ambitious task, but I think I am up for it. The real problem is finding free time to work on it. But I'll figure that out too.

[uberlinuxguy]

I finally had a bit of time to think about things, and perhaps this isn't the best approach, but here are some notes on a thought of mine on a new video mode based off of mode 1 and/or 5:

- similar to mode 1 or 5
- 8bit indices for tiles
- separate 1.6k max(adjustable) tileset RAM buffer, used to draw a "window" on screen of up to 196 tiles. (should be configurable, in size and memory usage.)
- function to load tileset from SD and/or SPI RAM, if present (this might be a timing constraint that makes this impossible)
- defines (in code or compile time) to determine window top,left,bottom,right (might be static or might be movable during runtime)
- renderer will switch between flash and the tileset buffer when drawing pixel data based on the window position defines.

Not sure if that helps visualize my idea, but that would give me up to the 14x14 window I would need to draw the "room" stuff. Only issue is it doesn't give me any sprites. For the interact-able objects in the room. I might have an idea for that too, which is to kind of modify the room map that is loaded in that part of vram buffer as the user interacts with the room.


I realize this could use A LOT of RAM, and I only have 4k to work with, much of which is probably consumed by the normal rendering routines. So perhaps this is a non-starter before I begin. This idea could possibly be easily adapted to using SPI RAM, but pulling a single byte from SPI RAM might be too much of a time constraint to be doable inside the rendering routines...

I have no idea if any of this is possible, so before I start coding something, I thought I would spew my cranial flatulations here for comment and thoughts from those who are more in the know before I start coding.

[D3thAdd3r]

I think you would run into a problem because 196 tiles at 8 bits per pixel will be 12544 bytes. At 2bpp it would only be 3136, but you would still need around 588 bytes for the regular vram indices on the rest of the screen(for 224x224 resolution). That is pretty close to doable on ram, but I suspect not quite, and limited 4 global colors wouldn't be good. If following the NES you could do 2bpp, with only 1 bit per 8x8 section to determine 1 of 2 possible 4 bit pallets for that 8x8 piece. The NES hardware must conform to that restriction. I could be wrong on the feasibility of local ram only though. This type of game has been discussed a couple times with no obvious solution.

The only way I see the SD card solving this is some SD background+sprites method. No way CunningFellow could figure anything out for this...

I vote for SPI ram, but then again I think all consoles should now ship with the expansion for just a bit of extra $ For the next UCC I think I would want to sponsor a couple extra console prizes so 4th and 5th get one, and 1-5 get the expansion to justify work on Uzenet anyways.

[uze6666]

Uze: If you haven't played Shadowgate, stop what you're doing right now and play it. Amazing game, amazing soundtrack.

I'd love to see this work on the Uzebox, but man does it sound ambitious ;P

Well, I assumed that now I had to finally play it. Played for a couple hours straight and I agree its a pretty cool game although most of the time it is not so easy to figure out what to do. It's a pretty ambitious game even if the video mode wasn't an issue.

[uberlinuxguy]

So I have made some headway on this, I was blocking on getting SPI RAM to work in Uzem, which I think I finally have. I just looked at that forum though and it seems Uze6666 has been up to doing some pretty damn nice changes, so I'm not sure how to merge the massive changes I have done with the massive changes he is doing. But I can open a thread there to stay on topic.

I started looking into a new video mode to try to figure out how to handle this and pouring through the docs on how that works, it seems that timing is everything. After doing some back of the napkin calculations, I think as far as pulling things from SPI RAM I might be running into trouble. I came up with an idea to pull a scanline's worth of SPI RAM pixels into a RAM buffer which is updated at the end of each scanline, but I still think I may wind up in a timing problem.

One of my questions is, aside from Uze's recent cool changes to Uzem, what would the best way to figure out your cycle per scanline count be?

Maybe I need to look into how mode 7 and the video player work to see if what I am trying to do is feasible. I'd imagine it is streaming stuff right off the SD card...

[uze6666]

One of my questions is, aside from Uze's recent cool changes to Uzem, what would the best way to figure out your cycle per scanline count be?

Right now, you can use the wdr instruction to count elapsed cycles in between executions. It will print it in the console.

Full screen video from the spi ram may not be doable at a decent resolution (240x224).
The test mode with spi ram I made had 360x240 @1bpp: http://uzebox.org/forums/viewtopic.php?p=14652#p14652. 2bpp would be a mere 180x224.

[uberlinuxguy]

The window is only 112x112. I wasn't necessarily planning to render the full screen from SPI RAM. The rest of the screen can be rendered using the normal tiles method from PROGMEM. So the mode I am thinking of writing would be a hybrid that has a predefined window that is configurable via compile defines. Let's you set the location, and size that it will pull from SPI RAM (Probably from a predetermined location) I was just thinking about how I would do the bits per pixel... 8bpp seems far too much and a bit too heavy, even in SPI RAM sequential mode (which I haven't really even written yet.)

I still need to play with getting the uzem140 branch working, so perhaps i can play with that once I get it working.