VDPX: The Quest for High-Performance Retro Graphics

Página 5/21
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

Por MagicBox

Master (198)

Imagen del MagicBox

05-10-2008, 01:03

@PingPong:

128 patterns are cached; not the unique patterns in use. When I would have to see if a pattern was already loaded, I would have to build a list of already loaded patterns. I would have to remember pattern start addresses (in cache) for each sprite. Building and checking lists is a dynamic thing both in time and processing which makes this much more complex.

Digital logic is unlike a CPU, you can't easily build lists, scan them to see if something already exists etc. Adding to, and scanning a list costs a dynamic amount of time, as is with CPU execution. Digital logic however follows a fixed pattern, both in processing and time. VDPX isn't acting like a CPU. (To clarify, a CPU is ofcourse digital logic, but unlike the program, the atomic operations (the individual instructions) are not dynamic, except for a few repetitive operations like LDIR and OTIR. It's the program that runs that makes the whole thing dynamic)

This means that patterns are loaded for all 128 sprites, even if all 128 sprites use the same pattern. You won't have to worry about losing blitter time though, loading 16KB worth of data like said is done in a mere 1.5 scanline, leaving you over 250 scanlines of time to blit stuff around.

----

Sprite linking: This is something I can look into, but will be difficult to implement if at all because there are 4 processing cores, 4 sprites are processed at once. In this context, the "previous" sprite is 4 sprites back. I will have to find a way to allow you to set the 'leading' sprite, and for relative sprites, which leading sprite they would belong to. I may get it to work, but with limitations like: Only every 4th sprite can be a leading sprite (0, 4, 8, 12 etc) AND any relative sprite MUST be a higher number. Sprite 3 can not be relative to leading sprite 8 for example, as sprites are processed from 0 - 127, 4 at a time, in just one pass. At sprite 3 I won't know the coords of sprite 8 yet. Perhaps flipping may still work (negating the offsets for the relative sprites and flipping the sprites themselves)

Por flyguille

Prophet (3028)

Imagen del flyguille

05-10-2008, 07:33

I thinks, the most programs beneficied by the 32x32 block or the linked sprites SYSTEMs are BASIC programming....because they are slow, as to use seven or eight PUT SPRITE n+x,(x,y),pttrn and you sometimes will see frames width the character repositioned partially

Offcourse that if the access to sprite's att table are fast, and for machine code is just some LD (),a or OUT(),a on a VBLANK the linking or blocky system is good, but can be done without it anyway....

Now, obvious, the leading sprite must be with a most top rendering number .... but, Is better that there wiill be just one BIT per sprite indicating that this is linked with the NUMERIC - 1.

When i readed to _wouter I figured out this:

How hard can be.... at att table

Sprite 0 = abs XY
sprite 1 = link = enable, offset xy (meaning only and ONLY linked to sprite 0 offcourse)
sprite 2 = link = enable, offset xy (meaning only and ONLY linked to abs result sprite 1 offcourse)
sprite 3 = link = enable, offset xy (meaning only and ONLY linked to abs result sprite 2 offcourse)
sprite 4 = link....

and in that way goes the chain

so, in the game code

one can set sprite 1 offset 0,16
sprite 2, offset 0,16
sprite 3, offset 0,16

in that way you define a sprite block of 0,64 size

obvious offsets values must be signed.

thinks in a SKANE a live SKANE.... rounding & rounding each part relative to the its predecesor sprite

To link sprites of arbitrary NUMBER is just USELESS and fULL MORE COMPLEX....

Por PingPong

Prophet (3889)

Imagen del PingPong

05-10-2008, 08:55

Leaving sprites at 16x16 pixels and having more sprites is a lot flexible than having less sprites with a bigger size.

If you want a bigger sized sprite just aggregate more sprites....

if you had a bullet of 3x3 pixels it's a huge waste of sprites using a pattern of 32x32 pixels.
I do not see any limits in 16x16 pixels sprites. The Sega SMS and NES sprite size was limited to 8 pixels....

@MagicBox:about digital devices and CPUs. I know both at the very low level since i've studied them, but my knowledge is about digital logic of the '80, so things like VHDL or Verilog appears to me as wonderful. In digital circuit degign i'm 'accustomed' to think about logic ports, flip-flops, latches, .... in terms of discrete components. I do not know the limits or features of those circuits.

To be designed manually even a simple old VDP sprite engine with 4 sprites units (like TMS) is yet at a good level of complexity.

Por wouter_

Champion (484)

Imagen del wouter_

05-10-2008, 10:00

Sprite linking: This is something I can look into, but will be difficult to implement if at all because there are 4 processing cores, 4 sprites are processed at once. In this context, the "previous" sprite is 4 sprites back. I will have to find a way to allow you to set the 'leading' sprite, and for relative sprites, which leading sprite they would belong to. I may get it to work, but with limitations like: Only every 4th sprite can be a leading sprite (0, 4, 8, 12 etc) AND any relative sprite MUST be a higher number. Sprite 3 can not be relative to leading sprite 8 for example, as sprites are processed from 0 - 127, 4 at a time, in just one pass. At sprite 3 I won't know the coords of sprite 8 yet. Perhaps flipping may still work (negating the offsets for the relative sprites and flipping the sprites themselves)

@MagicBox
You already told the sprite attributes are read in some buffer somewhere at the beginning of a frame. Wouldn't it be possible to adjust this buffer while fetching it from RAM (with only a couple of clockcycles delay)? That way the rest of the sprite system (e.g. the split-up in 4 processing cores) remains unaffected.

Anyway, just an idea, use it as you see fit.

Edit: And yes, as flyguille clarified, you can only link to the previous sprite number.

Por MagicBox

Master (198)

Imagen del MagicBox

05-10-2008, 10:23

+-----------------+
|                 |
| +-+ +-+ +-+ +-+ |
| |0| |1| |2| |3| |
| +-+ +-+ +-+ +-+ |
|  |   |   |   |  |
| ++---+---+---++ |
| | Prio Enc.   | |
| +------+------+ |
|        |        |
+--------|--------+
      Result

This is the sprite engine. It has 4 processing cores. Each sprite core has its own SAT and SPT cache for 32 sprites. The priority encoder passes on the sprite pixel and other attributes of the sprite that's valid for a given screen X/Y. The inputs to the engine are not drawn, but they are the screen X/Y and a start wire. Maybe this will show why linking to a "previous" sprite is not as easy as you think. The 4 cores are independant and do not cross reference each other. Apart from the pipeline latency, a sprite is fully processed in only one clock cycle. After 32 cycles the cores together will have processed 128 sprites (32x4).

THus, sprites are processed in this fashion:
0 1 2 3
4 5 6 7
8 9 11 11
12 13 14 15
...
124 125 126 127

Por MagicBox

Master (198)

Imagen del MagicBox

05-10-2008, 10:28

So, for linking to work in this model, you have to stick to one core. Only per core there is a previous sprite. Sprite 4, 8, 12, 16, 20 could all link to sprite 0. Sprite 5, 9, 13, 17 could all link to sprite 1. But sprite 3 can not link to sprite 0 as you are then crossing the core boundary.

Por MagicBox

Master (198)

Imagen del MagicBox

05-10-2008, 10:37

@MagicBox
You already told the sprite attributes are read in some buffer somewhere at the beginning of a frame. Wouldn't it be possible to adjust this buffer while fetching it from RAM (with only a couple of clockcycles delay)? That way the rest of the sprite system (e.g. the split-up in 4 processing cores) remains unaffected.

Anyway, just an idea, use it as you see fit.

That may actually work at no additional time cost, but it prevents proper flipping. You'd get something like this:

Normal:
         0 1 2 3

Flipped:
3  2  1  0

.. where individual sprites are flipped too. As you can see, the 'hotspot' for normal is as expected, top-left. But for the flipped chain, it's still at sprite 0, which is not top-left any more. Since at sprite 0 I don't know how many sprites are linked to its right, I won't be able to put the hotspot at the top left for the flipped version, which would be sprite 3.

Por MagicBox

Master (198)

Imagen del MagicBox

05-10-2008, 13:39

Well, this morning I did some wave-form test benches and am pleased to say that the sprite engine works perfectly (still with the sprite-mode, flip bits and the collision category system). Sprite linking however is not yet incorporated and will need to be sorted out well before I modify the engine again.

Por PingPong

Prophet (3889)

Imagen del PingPong

05-10-2008, 13:45

As for the sprite size i do not consider linking sprites , nor other forms of sprite aggregation, a *must* feature.

I'm also not thinking that 128 sprites will be fully used. Even if so writing the entire SAT, that if i'm not wrong is 128*8=1024 bytes is not a huge work for cpu....
I think instead having to manage 128 sprite AI could become a limit for CPU.

So why bother about some bizzarre features like those?

Simplicity always pay...

just my 2 cents

Por Yobi

Master (149)

Imagen del Yobi

05-10-2008, 14:36

Can you show us a movie of it?
Or some pictures of the results and dev. board. Cool

Página 5/21
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10