WIP: Shadowgate

Use this forum to share and discuss Uzebox games and demos.
User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: WIP: Shadowgate

Post by uze6666 » Thu Oct 15, 2015 3:32 am

His version does basically negate the benefit of using 3bit colors though? I would say whether 3 or 4 bits, whatever makes sprite blitting fastest is best; I really think that is going the be the bottleneck on this one. You should have loads of free ram on the 644 and SPI ram no matter what.
Not at all, it the same palette loop for 7 or 15 colors, so both are supported. Blitting would be faster in 7 colors mode. But you have to consider the NES can display up to 25 colors at once when combining all background and sprites colors. So I'd recommend to just use the 15 colors mode. It's going to be slower bu you do it once since it's a bitmap. And in such a mode and game you don't need 60fps (IHMO).
There would be some complication involved with sprites that overlap the SPI and tiles area, and though it could be done, Alec's idea seems more like mode 1 tiles that are 8x8 with no ram tiles for sprites over tiles. I thought that was no loss, but since then I see I overlooked the "MOVE" area at the lower left of the screen. You can free move the cursor over that part to select a direction. I have not played through the game, but you could probably also do that part as "snap to tile" like the rest of the menu is? It would definitely be easier for video mode code, at least for now it would be easier to get the video mode up and running to build motivation. My humble 2 cents.
In my proposed mode, the right section is indeed plain mode 5(like mode 1 but with 8 bit vram index) to allow enough free cycles to intertwine the preload of the next row pixel from the spi ram. The whole bottom part with the MOVE, would be mode 3 with sprites to allow arbitrary movement. So it's a 3-in-one video mode. The bottom part would be allowed to take the whole screen to handle title screen etc.

Lee's line buffer idea sounds pretty good and would indeed speed up the blitting.

User avatar
nicksen782
Posts: 667
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: WIP: Shadowgate

Post by nicksen782 » Tue May 21, 2019 12:05 am

What if there were no blitting other than for the cursor? Just a thought. ShadowGate really has minimal animations if you think about it (defined by smooth scrolling of any sprite.) Even the lightning doesn't "move". For example, freezing the lake has a gradual recolor effect. The dragon shooting fire isn't really an animation since you could just draw the flame moving downward tile-by-tile. In the throne room where you give the queen the scepter, yes, that does smoothly move something. Oh, and the snake when you get the staff too but even that is just a frame-by-frame. Nothing is "moving."

I've been experimenting with some ideas. For nearly every room in ShadowGate there are no tiles that also appears in other rooms. Perhaps duplicates on a solid color tile. But, in my testing, there was over 3800 tiles in ShadowGate and the vast majority of them were only used once in the whole game.

I thought that perhaps I could redo the graphics to maximize tile re-use even throughout rooms. I figured that 40 ram tiles might be enough. Any wall that looks like boulders are unique even within the same room for the most part. I tried to "uglify" it and I managed to get most rooms down to 40 unique tiles. This is a bit of a labor of love. I managed to whittle it down to under 2300 tiles. Still too many and that doesn't include the 14x14 map data for each room.

Tiles simply need to be smaller sized (byte-wise) for this to work. My thought was to have the room tiles all be ram tiles and then load maps and tiles from SPIRAM. There are far too many unique tiles in ShadowGate (even if uglified) to handle. Perhaps if some tiles (the few more common tiles) were in flash. But then you would need to have tile maps where some ids were ram tiles and some were flash and you would also need to make sure the correct ramtiles are loaded. For this, I would suggest using vram tile ids (and gConvert would need to accommodate this.)

I really think a game like ShadowGate is do-able but not without some serious reduction in unique tiles (and unique tiles per screen if using ramtiles for the tilemap.)

Any thoughts?

User avatar
nicksen782
Posts: 667
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: WIP: Shadowgate

Post by nicksen782 » Tue May 21, 2019 4:02 pm

... Just now thinking about it. The throne room is a sort of mid-way point. Perhaps store the tileset as two halves. Perhaps that would be enough if data from SD was swapped into SPI-RAM when advancing past that room. More of the original tiles could be retained.

It would be super cool to figure this out! Still likely need 40 ram tiles dedicated to the graphics though.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: WIP: Shadowgate

Post by Jubatian » Tue May 21, 2019 6:49 pm

Huh, I thought this got somewhat forgotten long ago... Even when designing Mode 45 recently, I took a look at this, but seeing how old the last activity was, I thought rather not bump it with some new random idea.

There were many interpretation of this game, too bad it apparently wasn't ever ported to the ZX Spectrum. The most minimal version was for Apple II, it has pretty high resolution though, anyway, I think it would be possible to get a rather convincing port in somewhat Spectrum style as well. With Mode 45 this would be quite possible on the bare "unexpanded" Uzebox.

Mode 52 also has some pretty decent capabilities in this regard, I purposely kept that potential use-case in mind to have reasonably large RAM based images displayed with it (such as for the monsters of an RPG battle scene), it could possibly do for a reasonably good Shadowgate port as well, and it is much easier to use than any of the other contraptions I designed (purposely keeping its interface as clean as feasible).

Otherwise I would say, CunningFellow could also have some decent ideas for a suitable mode when considering SPI RAM, probably Tempest's mode could be improved to provide a five colour quite high resolution mode. 1bpp background streamed from SPI RAM, 2bpp tiled foreground. Tempest's current limitation is that the background is black-blue as it exploits some hack. However for Shadowgate such high resolution is not that essential, so a lower resolution solution on a similar principle might do.

Just some random ideas, some even rather old (I probably though about Tempest in this regard maybe years ago, maybe even mentioning it somewhere).

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: WIP: Shadowgate

Post by CunningFellow » Wed May 29, 2019 10:18 pm

Tempest was a huge hack to get down to 5clk per pixel. (288/256 pixel wide) and it used/wasted a lot of flash to achieve this.

One of those hacks was that the 1bpp background had to be in the MSB of portc. It was just fortunate that the MSB was the brightest blue bit and that colour suited tempest. There was a version of the mode that could do any colour at 5clk but it trashed the bootloader. I was just one clock short for any of my other ideas to work.

If you dropped down to 6clk per pixel (240 pixel wide screen) you get 48 clocks per tile. Those extra 8 clocks could do a lot. You could easily get 2bpp+1bpp any colour background from SPI and save heaps of flash space.

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests