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 »

I'm starting to believe the 3+2 scheme will work with great care taken in the sprite blitter was used and perhaps a small amount of compromise. I simply cannot find any possible way it can be done with square ram tiles, so what if it was "ram rows"? At the start of each row check if it's an SPI row or a ram row(from 644 ram) and draw accordingly. For each ram row, it would still require some assembly and cost >700 cycles just to fill the line with the background data, then whatever it takes to blit on top of that. Besides cycles, that quickly exhausts the available ram if using a full 8bit pixel values, but that should draw anything the NES could... for the rows there was actually ram for.
sg_ram_rows.png
sg_ram_rows.png (5.25 KiB) Viewed 11791 times
For this method the 2+2 1024 byte pallet would work, and preferably that pallet could go into flash to give more ram rows. I'm haven't tried to see if it can still keep up when replacing the LD with LPM, not real confident it would, but this idea basically needs it to be so. It would be much more preferable to have 4bpp ram rows. Essentially it would take advantage that all 4 colors pallets have black at index 0, and that sprites can only have 3 unique colors. So if every possible 2 bit attribute were used, there would only be (16-4)+1=13 unique colors per row(since black is repeated). All sprites on a row would have to share the same pallet...ONLY if every type of attribute was used that line..I don't think that happens but, this could break since the cursor could go anywhere and could have different colors than some other sprite on the line..not sure on the fix for that besides having more pallets to point to at the beginning of a row or simply using the same colors as tiles for it. The sprite blitter, once the pixels are copied from the BG, could run through and build a pallet with all the unique colors required then add the sprite colors required. Then blit and set the flag it is a ram row and a pointer to the pallet to use for it. These custom pallets would only cost 16 bytes each at least. Each ram row would cost 112/2=56 bytes, then 2 more bytes to point to a custom pallet to use. There could probably be ~38-40 ram rows then, if the pallets can be flash.

Another crazy thought is to use the interrupt trick to jump in and out of ram row and normal SPI with IJMP, since the SPI line is essentially stateless. Sounds like CunningFellows area of expertise, it's pretty hard to say if that has any hope of working. The advantage would be perhaps that a ram row would not need to store pixels for every pixel in the row, this would allow a lot more. It's too difficult to investigate when I think it wont work in the end.
User avatar
Gosma
Posts: 68
Joined: Thu Oct 24, 2013 7:31 pm
Location: Santos, Brazil

Re: WIP: Shadowgate

Post by Gosma »

Cool!! another project that i want to see very much when it's done... :D
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 »

Been thinking about your last post and the ram lines idea. I made some calculations and it appears we can have a full resolutions mode (240x224) with some compromise on the layout. A picture is worth a thousand words:
shadowgate.png
shadowgate.png (11.27 KiB) Viewed 11715 times
The left part would use the 15 colors mode like mode13. The right part would be a bit restricted since it can't have sprites. But that should not be too bad, just need to have a couple more tiles for the hand cursor in different positions and backgrounds.

Here's the code that should work. It's surprisingly simple. Perhaps too simple, so take with a grain of salt! :)

Code: Select all

	mov r18,112/2
bitmap_loop:
	in ZL,SPDR		;read next 2 pix from spi ram
	ld r16,Z+		;pal pix1
	out PORTA,r16

	out r17,SPDR
	ld r16,Z		;pal pix2
	rjmp .
	out PORTA,r16
	
	nop
	ld ZL,X+		;load next two pixels from buffer
	ld r16,Z+
	out PORTA,r16
	
	rjmp .	
	ld r16,Z
	dec r18
	out PORTA,r16
	
	brne bitmap_loop
	
	;X=buffer
	;Y=VRAM
	in r16,SPDR		;read next 2 pix from spi ram+,
	out r17,SPDR	;start next spi ram read
	ld ZH,Y+		;next tile
	ldi ZL,line_offset	
	
	...etc...prepare for tiles only section
loop2:	
		
	lpm r0,Z+
	out PORTA,r0
	
	st X+,r16		;store to buffer
	lpm r0,Z+
	out PORTA,r0
	
	in r16,SPDR		;read next 2 pix from spi ram+,
	out r17,SPDR	;start next spi ram read
	lpm r0,Z+
	out PORTA,r0
	
	st X+,r16		;store to buffer
	lpm r0,Z+
	out PORTA,r0

	ld r25,Y+		;next tile
	lpm r0,Z+
	out PORTA,r0
	
	ldi r24,line_offset	
	nop
	lpm r0,Z+
	out PORTA,r0
	
	in r16,SPDR		;read next 2 pix from spi ram+,
	out r17,SPDR	;start next spi ram read
	lpm r0,Z+
	out PORTA,r0
	
	lpm r0,Z+
	movw ZL,r24
	dec r18
	out PORTA,r0
	brne loop2
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: WIP: Shadowgate

Post by uberlinuxguy »

Wow you guys! I go away for a while on a vacation and come back to you all coming up with awesome stuff like this. I may have some time in the next few days to test some of these ideas if you all don't have the time. I assume the code you all are posting is what goes in the rendering function? (I can't recall the name at the moment and am typing this on my cell)
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

uze6666 wrote:The right part would be a bit restricted since it can't have sprites. But that should not be too bad, just need to have a couple more tiles for the hand cursor in different positions and backgrounds.
That seems no real loss since the NES version snaps the cursor to tiles anyway.
uze6666 wrote:Here's the code that should work. It's surprisingly simple. Perhaps too simple, so take with a grain of salt!
Nice...after as much scrutiny as I can think up, I firmly believe that works perfectly. Very elegant, funny how it looks simple, after it's all discovered and laid out in code. I'll risk premature celebration to say you have nailed this thing Alec :ugeek:

Next question would be how many cycles will it take to erase then blit the cursor and any other things that might need to be sprites to it? Might be worth double buffering it since there is gobs of SPI ram free there.
Last edited by D3thAdd3r on Sun Sep 27, 2015 5:36 am, edited 1 time in total.
Reason: couldn't manage to type ']' in "[/quote]" the first time
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 »

I suspect blitting wont' be fast, but for such a game, it's not required either. Even if it take a couple frames, it won't make any difference. That said, I agree with you that double buffering would be to way to go to avoid seeing things draw itself progressively.

To avoid all the issues of concurrency mentioned in the spi ram thread, I think that only the kernel should access the spi ram for such a video mode. As proposed lately, a command queue could be used by the main program to send operations like load from SD, blit a sprite or write a string. Again, since we don't need 60pfs animations here, that could prove much simpler and elegant.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

I tried having a conversion pallet generated automatically but I did not like some of the color choices. Really, the issue is that in some instances, it is the same Uzebox color that is the closest possible(mathematically) to a couple NES colors, so of course the program choose those for both instances. I just did it manually again and I think it's better. Some "artistic liberties" were taken where 2 NES colors were closest to the same Uzebox color. Instead the closest one gets the color, and the other not quite as close one gets some other shade, perhaps a tinge of blue, as Uzebox greyscale relies on darker shades of blue coming across as the same idea IMO. So, yeah exciting...it's a table :roll: And the NES really does have that many black shades, so it's not really 64 unique colors...except NES has rarely used "emphasis bits" that change all these colors...confusingly they are more like "de-emphasis bits" much like our fader..not an issue for this one.
nes2uzebox_pallet.png
nes2uzebox_pallet.png (5.74 KiB) Viewed 11656 times
Both pallet images here are actual output pixel colors from each system on their respective emulator

Code: Select all

0x52,//NES COLOR 0x00
0x40,
0x80,
0x81,
0x42,
0x02,
0x03,
0x04,//...2 is more accurate
0x0A,
0x08,
0x10,
0x11,
0x48,
0x0,
0x0,
0x0,



0xA4,//NES COLOR 0x10
0x90,
0xC8,
0xC2,
0x84,
0x45,
0x0D,
0x0C,
0x13,
0x19,
0x18,
0x1A,
0x58,
0x00,
0x00,
0x00,


0xFF,//NES COLORS 0x20
0xE2,
0xDB,
0xDD,
0xD7,
0x9F,
0x5F,
0x27,
0x2D,
0x2B,
0x31,
0x71,
0xE8,
0x49,//no close option
0x00,
0x00,


0xFF,//NES COLOR 0x30 //0xBF is second closest
0xF4,
0xED,
0xEE,
0xEF,
0xE7,//0xEF is closer
0xAF,
0xB7,
0x77,
0xB6,
0xB5,
0xB4,
0xF3,//0xF4 is closer
0xE5,
0x00,
0x00,

There are also many colors that are dead on accurate, so conversion should have minimal noticeable differences. For sure when you put sprites on and have the limit of 16 colors, there are going to be some pallet design choices to make.

At least putting it on the forum I will never have to redo it. Basically that's what I mean by extracting the pallets from the rom, you use those values with the attributes for that part of the screen using the tile numbers you extracted....using 1 2bpp tiles you extracted..to look into this table and convert to a graphics format Uzebox can use...I hope.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP: Shadowgate

Post by D3thAdd3r »

Looking at the last couple pallet entries on my cellphone screen I realize 2 things, my laptop has a pretty washed out screen, and I will need to choose different colors for those ones(too purple).
tileandmaps_ripped.jpg
tileandmaps_ripped.jpg (58.07 KiB) Viewed 11639 times
screen2.jpg
screen2.jpg (33.85 KiB) Viewed 11623 times
I fixed some small things so the ripper actually grabs the map correctly, I also implemented tile ripping and conversion. Need to fix some offset on pallet conversion mainly, but this is just a quick visualization, it is actually useless to have these as flash tiles. Obviously it is all 1 4 color pallet, the reason is because the planar NES graphics are currently grabbed and interpreted verbatim as entries into the 1st pallet, or first 4 colors, for that screen. NES graphics do not convert 1:1, because Uzebox normally has full 8bpp ANYWHERE, where as NES has 2+2 bits as I rambled about previously. I currently have the the attribute bits ripped, but it is not possible to know which colors a tile will use without knowing where it will be on the screen and what attribute bits affect it(hence why when viewing NES graphics in TLP or such, getting the right colors is not trivial and wont be right except for some of the tiles). Some tiles could be draw with 1 name table in 1 place and a different one in another for example, where you would have to store that as 2 different tiles on Uzebox...and that will affect the tile maps.

Not going to worry about that pain since the goal isn't to rip into 8x8 flash tiles, but instead blit 14x14 8x8 pixel tiles into a bitmap, and use the location of each tile to determine the attribute bits for it's location for pallet lookup, and fix whatever I screwed up on pallet ripping. Then it will be a 112x112 bitmap with the right colors, and from there it should be ready to composite into an SD card image to blit to SPI ram. One small piece here and there gets it done.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: WIP: Shadowgate

Post by Artcfox »

Looks awesome!
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: WIP: Shadowgate

Post by uberlinuxguy »

I know that D3thAdd3r is doing some really cool and awesome work on ripping the graphics, but I just stumbled across something interesting...
shadowgate.png
shadowgate.png (319.6 KiB) Viewed 11576 times
Wonder if that seems helpful? Looks like all the screens and sprites. Also looks like some parts of some screens draw outside the "window" over the checkers and into the black part.. might throw some annoying monkey wrenches in... :?
Post Reply