WIP: Shadowgate

Use this forum to share and discuss Uzebox games and demos.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

Oh wow, I could not find that, but it was fun anyways and I got the code/pallet to convert NES graphics(again) if it's ever needed.

It is the way to go, does your source have the text as well? I'd say if you get those layed out with each screen below the next vertically and you might be able to use gconvert to turn it into 112x112 "tiles", take that output hex and convert it into binary for the SD image. Alec's video mode concept really should work and you would have the data all ready for test drawing!
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: WIP: Shadowgate

Post by uberlinuxguy »

D3thAdd3r wrote: It is the way to go, does your source have the text as well?
Nah just graphics.
D3thAdd3r wrote: I'd say if you get those layed out with each screen below the next vertically and you might be able to use gconvert to turn it into 112x112 "tiles", take that output hex and convert it into binary for the SD image. Alec's video mode concept really should work and you would have the data all ready for test drawing!
I guess I should also figure out how to map the colors right, per your NES to Uzebox mapping. And the text, but you sort of had that figured out.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: WIP: Shadowgate

Post by uberlinuxguy »

So I started playing with that idea, and have a couple of questions:

I have an indexed image, to the uzebox palette, that contains 3 rooms. I used a python script to convert the output of gconvert (after some regex replacements) to just byte values in a file. The problem is, Uze's code is assuming 4bpp but the uzebox palette is a 1 byte per color table yes? What would be the easiest way to convert that to something 4 bpp + palette as Uze suggests? Is that my own color palette that is used to map things? I suppose I could figure out how many colors would be required total and somehow make a map, stored in flash, that maps 4bpp to the full uzebox palette map.

Then I have to figure out the other parts of the screen...
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

I seem to have missed this one in the flurry of forum activity.
uberlinuxguy wrote: Is that my own color palette that is used to map things? I suppose I could figure out how many colors would be required total and somehow make a map, stored in flash, that maps 4bpp to the full uzebox palette map.
You get to pick your own pallet. I never found a good way to deal with that stuff, I did it manually for a couple things, but it isn't fun. I think we need gconvert to automatically generate a 16 color pallet for it basically. I think you would probably need to recolor somewhat the level and sprite graphics, so they do not use more than 15 unique colors between them for the video mode to work correctly.
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 »

The way i see it, you would allocate like 2 or 3 fixed colors for the cursor and have a custom program build the required palette for each screen. All sprites that has to appear in a screen should be pre-superimposed for that pass.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

The hardest part of doing a custom program for generating pallets I feel is taking into consideration you might need more than 1 pallet for the image to be converted. As would be the case where you composited all the screens together vertically into a single image, how does the program know where it should start making a new pallet. Also what fixed colors should always be in every pallet for a cursor or such. The easiest solution I figure is to simply have images that only contain graphics that will use the same pallet, and have more images converted separately(1 for each level even). Does that solution seem OK if you were able to specify off the command line some colors to have at the beginning of the pallet or a file to read the colors from?

More complex, you could specify start positions with width and heights in a XML file where a pallet should be generated from like how gconvert does the maps. I never checked how hard it is to implement XML parsing but it doesn't seem trivial.
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 »

Why not have a distinct 15 color palette for all and every 112x112 screen?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

Definitely agree you need a separate palette per level. That's what I was attempting to put into words. Just to be clear, you do envision using gconvert in the process? Also, it would be a multiple pass where gconvert and a palette tool would operate on the data separately?

It is a hurdle I would love to see solved, and though I think it is possible, I never saw any obvious generic way to do such things that is configurable enough to work for any needs. I think the requirements are output graphics data that is in correct compressed format pointing to the correct indices (which user is responsible to set the palette correctly at run time) as well as 1 big array that contains all palette data sequentially. It must also allow a "sub palette" of fixed colors (like for the cursor) that are automatically inserted to the first indices of each new palette and new colors in each level graphics are inserted afterwards; with correct indices offset considering the number of "sub palette" entries. It has to work from the makefile, and there needs to be the ability to specify tile dimensions, how many palettes should be generated, and foreach palette the x and y coordinates to start from. Obviously each pixel it encounters look up to see if it's an existing one, else insert a new one and use that.

It seems both gconvert and the custom tool would be duplicating some of the same work to determine what indice a pixel should point to (it has to be aware of how many colors there are and where in the palette they are to output correct compressed pixels), which doesn't matter, except if gconvert is already parsing XML it might be easier to squeeze in there anyway? I thought the easiest process might be to run gconvert code as usual, then do a second pass on the output file data to change raw pixel values to indices and generate the palettes. It would keep the complications and bugs away from the long proven existing gconvert code and be a separate entity basically...though sure a separate program can do it just the same.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: WIP: Shadowgate

Post by uberlinuxguy »

I was planning on implementing something into the gconvert code that when you gave it a certain flag, instead of outputting a .inc file, it would output a .dat file with just the pixel data (indices) and an option to "compress" the data into a palette of X bit per pixel (or possibly just palette size not sure yet)

I'm pretty sure if I did an individual palette per screen/level, I could get away with 3bpp, or only 7 colors (plus black as zero.) If not, it wouldn't be too hard to adjust it to 4bpp. But the bpp would specify how many colors you could have in the palette. Then the palette would just be output as a header to the image. So in my case, at 3bpp, I would have 7 bytes at the beginning of the level data that would be loaded internally in the video mode code, possibly in a palette buffer, then all the 3-bit sequences would reference that palette. So gconvert would be outputting 3-bit sequences into the data file for each pixel referencing to the embedded palette. Then you code the SPI part of the video mode around that. The rest of the screen should be able to come out of normal "mode 3" like rendering, as well as any sprites that get meshed in (although I might need some help blitting that onto the SPI part...) If you maintain an array of sprites, I would imagine you know where they are and the video mode can switch out of SPI RAM mode for those pixels when they are encountered and reference the pixel data from the sprite.

How's that sound guys?

--
Jason
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

uberlinuxguy wrote:I'm pretty sure if I did an individual palette per screen/level, I could get away with 3bpp, or only 7 colors (plus black as zero.)
I do suspect that you are right which is why I thought the video mode idea I had might have worked with minimal or no graphics modifications. It was needlessly big and complex and Alec's version, being simpler and having unlimited sprites, is better. 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.
uberlinuxguy wrote:The rest of the screen should be able to come out of normal "mode 3" like rendering, as well as any sprites that get meshed in (although I might need some help blitting that onto the SPI part...) If you maintain an array of sprites, I would imagine you know where they are and the video mode can switch out of SPI RAM mode for those pixels when they are encountered and reference the pixel data from the sprite.
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.

On sprite blitting the slowest part should be jumping the address around to each new row. There seems no option for speed but to blit sprites horizontally, then stop and change the address to the row+x offset for the next pixel underneath that sprite line. Even at 18 cycles a piece, that is not too many for the actual pixel drawing on a sprite that is somewhere around 32 pixels(576 cycles per sprite row). I wouldn't doubt that it is not possible to do 60 times a second.

To draw the next frame you need a fresh copy without old sprite pixels on it, that seems a lot faster than jumping around and cleaning up scattered pixels that actually had a sprite "corrupt" it. Only way I can think is to have a large line buffer in 644 ram and keep a plain version of the background elsewhere in SPI ram that never gets drawn over. Read from the SPI ram to the line buffer until it's full, then put that information over the buffer you are actually working on until you have a fresh copy...then draw sprites over. Double buffering ensures you are not required to get this done in 1 frame at least.
Post Reply