WIP: Shadowgate

Use this forum to share and discuss Uzebox games and demos.
Post Reply
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

WIP: Shadowgate

Post by uberlinuxguy »

So perhaps I am glutton for punishment, or perhaps I am clinically insane. Either way, on top of the work on the SPI RAM stuff and getting that to work in the emulator, I've got it in my head that porting Shadowgate might be rather easy. However, I am running into a few things that I am not expecting. I'm not sure if this forum is the place to discuss my experiences while attempting the port or not, so if this is not the place, please direct me to the right place and I will happily move the thread there.

Shadowgate is a pretty simple interface. There is main screen that contains a "window" that displays the "room", a "scrolling" list of inventory items, and a message box/action box at the bottom. Seems pretty straight forward, but I am a bit confused about how I should be able to draw to the screen (and if I am even using the right video mode.)

Back in the old days, I used to do DOS based screen writing stuff by setting up the background of the screen the way I want and just iterating over the sections I want to change in my main loop. From my first attempts at the Shadowgate port, that does not seem like the way Uzebox can do things. And that's probably ok, but that runs me into a few issues. My first one is understing how to load other tile sets to draw parts of the screen from after establishing what the background(or static part of the screen) looks like. I read a few of Weber's tutorials and a bunch of the documentation about this stuff, and some of it is becoming clearer as I work through it practically, but I think I have more reading and experimentation to do about the video system before it makes complete sense to me. Guidance is always welcome though, examples are extremely welcome. :-)

If I can get Shadowgate to work though, I think there is another game with a similar layout that I would probably do, since it is just a matter of graphics and logic changes.

I think another big part is going to be figuring out how to "dynamically" load the logic bits that will handle the rooms and such. The game has upwards of 45 or so rooms. I can probably code all of that into 1 static logic system, but a clever bit, if I want to attempt a larger version of one of these types of games, would be to handle the logic dynamically. Sort of pre-compile bits of code like a "shared library" style thing, and dynamically load and unload them as I need. This could be tricky too, and I am curious if anyone else has run into the issue where your game logic alone out grows what Uzebox can handle.

At the moment a lot of this is just musings as I'm still not 100% familiar enough with the system to know if I can pull this off. From a graphics stand point: it seems with the SD card and, if needed, some clever pre-loading the tile sets into something like SPI RAM, I can probably make that work once I wrap my head around the video system(s) better. From a logic stand point: I can probably make this work too either with a static set of logic handlers, or with some kinky sort of dynamic system that loads from the main game .dat file (which will contain the tilesets and everything else). Saves are another thing I haven't quite figured out yet, but I still have to conceptualize the idea of a "game" object, how I want to represent that, and if it all fits into RAM without stepping on the graphics side of thing.

I suppose I am starting this thread for some feedback more than anything before I dive too deep into this one. Now that I have sort of started on a game, I can see how much work goes into porting it. It's a fun distraction from life while you are thinking/doing it though. :D
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

I am not familiar with the game but it looks like a good one to do. Are you wanting it to end up looking like this?
Image
For that big of a screen and many unique tiles, I'm assuming ram tiles tricks wont help you much on that. The bitmapped modes will probably not give you enough color or resolution for what you want to do. 45 screens of various tiles will probably eat your flash quickly. I do think you want to utilize SPI ram for anything you can, it would be cool to have some interpreted logic tokens in ram loaded from the SD and it might even be reusable to other projects. The Uze8 chip emulator basically does that, but you probably want higher level code. I do think you want a custom video mode to do it justice, a mixture of RLE 1/4 screen +tiles might work well.

I put up a small tutorial for using TileStudio here. I'd be interested to see if anyone else comes up with different results for shaded graphics between the 2. This is definitely the place to talk technical game stuff, after all what fun would any of this be without like minded souls interested!
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

The NES version has the actual part you might want bitmapped at 112x112 pixels. The second half could be 8x8 tiles. I haven't tried much with assembly since playing with the raycaster thing and I'm nervous to ever show asm ideas I have(for fear of my newbiness showing). This idea got stuck in my head and I got back up and had to take a crack at it before I sleep; it was bothering me that it could be possible to have a bizzare hybrid SPI/local 644 ram vram. The screenshots I see look like an 8 color mode would suffice, unfortunately SPI ram is too slow to output 3 bits every 6 cycles, so preload some registers up with the MSbit of the 3rd pixel we don't have time for and use all inlined code until we get to the tile part. The first 2.66 pixels are from SPI ram and it only takes 1 bit of local ram for every 3 pixels so we shouldn't run out with no ram tiles taking up space. Alec and Cunning tell me if I missed something silly.

Code: Select all

///////////////////////////////////////////////////////
//draw 112 pixels wide, then switch to 6x8 tile mode each scanline
//must have bytes in r0,r1,r2,r3 representing "extended bits"
//must have inlined code for every pixel with correct r0-r4 bit offsets
//must have .256 aligned 256 entry pallet of repeating 8 colors
//YH must be preset to hi8(pallet)

//Pixel 0
	in YL,SPI//get SPI byte for 2.66 pixels
	out SPI//queue next read
	ld r17,Y//get pallet color for pixel 1
	swap YL//get next pallet offset ready
	out VID,r17

	ld r17,Y//read pallet color for pixel 2	
	bst r17,3//save b0 for pixel 3 in T
	bld YL,0//store b0 for pixel 3
	bst r17,7//save b1 for pixel 3 in T
	out VIDEO,r17
	
	bld YL,1//store b1 for pixel 3
	bst r0,0//save b2 for pixel 3 in T**********variable offsets and registers*********
	bld YL,2//store b2 for pixel 3
	ld r17,Y//get pallet color for pixel 3
	out VID,r17


//Pixel 1
	in YL,SPI//get SPI byte for 2 2/3 pixels
	out SPI//queue next read
	ld r17,Y//get pallet color for pixel 1
	swap YL//get next pallet offset ready
	out VID,r17

	ld r17,Y//read pallet color for pixel 2	
	bst r17,3//save b0 for pixel 3 in T
	bld YL,0//store b0 for pixel 3
	bst r17,7//save b1 for pixel 3 in T
	out VIDEO,r17
	
	bld YL,1//store b1 for pixel 3
	bst r0,1//save b2 for pixel 3 in T****************************
	bld YL,2//store b2 for pixel 3
	ld r17,Y//get pallet color for pixel 3
	out VID,r17

/////....
/////....

//Pixel 8
	in YL,SPI//get SPI byte for 2 2/3 pixels
	out SPI//queue next read
	ld r17,Y//get pallet color for pixel 1
	swap YL//get next pallet offset ready
	out VID,r17

	ld r17,Y//read pallet color for pixel 2	
	bst r17,3//save b0 for pixel 3 in T
	bld YL,0//store b0 for pixel 3
	bst r17,7//save b1 for pixel 3 in T
	out VIDEO,r17
	
	bld YL,1//store b1 for pixel 3
	bst r1,0//save b2 for pixel 3 in T****************************
	bld YL,2//store b2 for pixel 3
	ld r17,Y//get pallet color for pixel 3
	out VID,r17

//Pixel 9
	in YL,SPI//get SPI byte for 2 2/3 pixels
	out SPI//queue next read
	ld r17,Y//get pallet color for pixel 1
	swap YL//get next pallet offset ready
	out VID,r17//PIXEL

	ld r17,Y//read pallet color for pixel 2	
	bst r17,3//save b0 for pixel 3 in T
	bld YL,0//store b0 for pixel 3
	bst r17,7//save b1 for pixel 3 in T
	out VIDEO,r17//PIXEL
	
	bld YL,1//store b1 for pixel 3
	bst r1,1//save b2 for pixel 3 in T****************************
	bld YL,2//store b2 for pixel 3
	ld r17,Y//get pallet color for pixel 3
	out VID,r17//PIXEL
//Now draw normal tile mode for the second half...
You would have 2 types of scanlines. 1 that is half bitmapped from SPI ram for the first part of the line(well there is that little checkerboard you could easily do while preloading stuff). The second half is regular tiles from vram. The second type would be normal tiles below the hybrid bitmap/tiles lines of course. You would of course have to make a conversion program that knows about this twisted format to store it on the SD, then code to load it into the..err..2 different vrams.
User avatar
kivan117
Posts: 73
Joined: Sat Mar 14, 2015 5:43 am

Re: WIP: Shadowgate

Post by kivan117 »

I hope this project progresses well. Would add another of my dream projects to the Uzebox library.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: WIP: Shadowgate

Post by CunningFellow »

I agree this looks like a case for a custom video mode with a bitmap straight of SD card for the 112x112 pixel window.

Does it need to be 4, 8 or 16 colours ?

Start throwing forward ideas everyone.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: WIP: Shadowgate

Post by uze6666 »

Looks like a cool game, never saw it before. I think you code looks ok at first glance. But I'm not sure I would couple the game to spi ram just for the sake of it if the SD can do it too since that would restrict the game to too few peoples. That said, you could enhance the game when the spi ram is there. Like adding more color depth perhaps?
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: WIP: Shadowgate

Post by CunningFellow »

First glance looks like you should have enough clocks to

Store a 128 pixel wide 4bpp bitmap on SD card
Pre-Read bytes of SD card into a 64 byte circular buffer
Read bytes of SD card as you are decoding and displaying 4Bpp on those scanlines that have a vertical mode split

The 128 pixel wide bitmap at 7 or 6 clocks per pixel and then the text part of the screen at 5 clocks

With nothing more horrible on flash usage than unrolling a single scanline (about 3K flash usage) and 320 bytes of RAM usage for the pallet and the buffer
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: WIP: Shadowgate

Post by uberlinuxguy »

I was kind of leaning towards agreeing with Uze about the SPI ram. I wasn't planning on tightly coupling the game to it, but perhaps enhancing it somehow or something if it was there.

Custom video mode eh? That just got quite a bit more complex, but probably not yet outside the realm of what I am willing to attempt.

I'm not yet sure I understand what D3thAdd3r's code does, but I've been too tired to wrap my brain around it yet. Perhaps I will re-read it this weekend and see if I get it.

So far, this sounds like tons of fun! Need to read up on the suggested RLE stuff.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

I just turboed through a playthrough of the game on youtube and, just eyeballing counting it, I'm convinced it's never more than 8 unique colors anywhere. There is definitely never more than 4 colors per 8x8 tile since it's NES. It would be a better general purpose mode with 16 colors, but if you had to sacrifice resolution perhaps not. I don't think it's an overstatement to say it would be an epic task to actually go through and add colors/details to all those screens. The graphics of the other game you might use this mode for would have some weight on whats required and what is not.

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. So you would basically have to make an SD frame for every possible combination of object states on every screen. The space on the SD card probably wouldn't be a problem, maybe a bit dubious, but the complexity to develop that sounds intense.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: WIP: Shadowgate

Post by CunningFellow »

128x128x4Bpp = 8K

256M SD card = 32,000 frames.

I'd say you would need to make a PC based program to make the "movie" file like I did with T2K, but I am sure it would not be large in comparison to the SD card.
Post Reply