videomode proposal - attributes with xor operand on tiles

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
User avatar
nitrofurano
Posts: 38
Joined: Wed Apr 15, 2009 11:10 pm
Location: Porto, Portugal
Contact:

videomode proposal - attributes with xor operand on tiles

Post by nitrofurano »

since Uzebox has its limitations when drawing each pixel in few cycles (between 4 and 12, depending on the videomodes available), i think would be interesting another videomode, using a colour attribute area (which does a xor operand over the colours from the tile in the same place - instead of drawing the colours from these tiles directly, they would be drawn after a xor operation from the attribute area)

for showing how this videomode would work, i tried to sketch it in an youtube video: http://www.youtube.com/watch?v=BWnck_eYhOg

since the text area from mode, with 8x8 tiles, in a 240x224 resolution, is 30x28, 840 bytes, the attribute area would take the same 840 bytes - 1680 bytes for everything. (of course these tiles could be also 6x8, 4x8, 8x12 or whatever, depending on the need of their developers )

how possible, interesting and useful would be a video mode like this?
User avatar
JRoatch
Posts: 108
Joined: Mon May 11, 2009 11:48 pm
Contact:

Re: videomode proposal - attributes with xor operand on tiles

Post by JRoatch »

xor or not you still have to load arbitrary pixel data, wherever it comes from ROM, RAM, or LDI instructions. So using xor to change the color is only gonna add 1 cycle to each pixel, which would need to be a total of 6 cycles for that resolution.

Is what you want is to be able to load individual foreground and background colors for each tile? If that's the case, I think there might some color limits that multiple xoring would bump into.
User avatar
nitrofurano
Posts: 38
Joined: Wed Apr 15, 2009 11:10 pm
Location: Porto, Portugal
Contact:

Re: videomode proposal - attributes with xor operand on tiles

Post by nitrofurano »

JRoatch wrote:xor or not you still have to load arbitrary pixel data, wherever it comes from ROM, RAM, or LDI instructions. So using xor to change the color is only gonna add 1 cycle to each pixel, which would need to be a total of 6 cycles for that resolution.

Is what you want is to be able to load individual foreground and background colors for each tile? If that's the case, I think there might some color limits that multiple xoring would bump into.
Overally, the tiles would be from Flash ("ROM"), and the 2k (text and attribute) from RAM.
Yes, there are colour limits - that's why i shown several combinations (1 per second in the video).
The idea is not only about only choosing individual foreground and background colours for each tile - i thought about this too, but i think it would be far harder to do in so limited cycles per pixel (but would be great if someone could find some idea and show it working anyhow).
I though about this idea since using xor seems to be what like you said, just taking 1 cycle (or maybe 2) from each pixel. The idea would be mostly going a bit beyond the 256 tile limitation, going around a combination of 65536 different tiles (256 rom tiles, and 256 xor attributes) without having to use too much rom or ram.
Maybe some perfectionist pixel-artists would struggle a bit with a feature like this, but people enjoy coding experimental/abstract games (a kind of games i just love, and sometimes really interesting stuff appears in the indie gamedev scene), or have no problems on coding picture converters for reaching the best result as possible from this limitation, may create wonderful results with this (imho).
User avatar
JRoatch
Posts: 108
Joined: Mon May 11, 2009 11:48 pm
Contact:

Re: videomode proposal - attributes with xor operand on tiles

Post by JRoatch »

nitrofurano wrote:I though about this idea since using xor seems to be what like you said, just taking 1 cycle (or maybe 2) from each pixel.
I really meant at least 1 more cycle in addition to the cycles for other processing.

For each pixel, the ROM loop normally consists of:

Code: Select all

3   lpm    get rom pixel
1   out    write to screen
2   ?      other processing
"other processing" is loading and computing next tile address, and loop management.

Now if we put xor (eor) in the loop, it becomes this:

Code: Select all

3   lpm    get ROM pixel
1   eor    xor with tile attribute
1   out    write to screen
1   ?      other processing
The problem here is that you sometimes need 2 cycles in "other processing" for instructions like LD, MUL, and BR*

Now it might work if you switch to RAM tiles

Code: Select all

2   lp     get RAM pixel
1   eor    xor with tile attribute
1   out    write to screen
2   ?      other processing
because now you have that room for that other processing.

If you want to save space and use only one bit per pixel, you'll probably end up with something close to Mode 6.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: videomode proposal - attributes with xor operand on tiles

Post by uze6666 »

JRoatch explanation is right on. Mode 6 would allow such a functionality, but it's a 1-bit mode.
Post Reply