VDPX: The Quest for High-Performance Retro Graphics

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

Por ARTRAG

Enlighted (6844)

Imagen del ARTRAG

04-10-2008, 13:00

VDPX should issue a number of interrupts!

1) command executed
2) line reached
3) sprite collision
4) what else ?

Por MagicBox

Master (198)

Imagen del MagicBox

04-10-2008, 15:16

Ofcourse it will. As for Z80's interrupt vector mode, it would require special programming. The original VDP's interrupts must be turned off for this (it doesn't support a vector value) and any new interrupt routine should be calling the original RST38 interrupt handler to make the MSX continue to function in basic. Even in normal interrupt mode, the original VDP's interrupt bits must be turned off; you want to be in sync with VDPX, not VDP Tongue

Por MagicBox

Master (198)

Imagen del MagicBox

04-10-2008, 16:38

Just thinking.. should VDPX get a BASIC ROM too?

Por PingPong

Prophet (3889)

Imagen del PingPong

04-10-2008, 17:18

Just thinking.. should VDPX get a BASIC ROM too?
to do?

Por MagicBox

Master (198)

Imagen del MagicBox

04-10-2008, 17:55

VDPX programming in BASIC

Edit: I also made a modification to the sprite engine. The SAT is no separate memory any more and is now cached from VRAM as well. This both made the sprite engine less complex and it will allow you to use the blitter on the SAT too whenever you wanted to do that in the first place.

Instead, I'm now going to have to write the Cache Controller, which reads the VRAM and stuffs the Sprite Engine memory (SAT & SPT). This thing is going to be reasonably complex Wink

However, Verilog is a great hardware description language and the source files aren't all that big either.

Por PingPong

Prophet (3889)

Imagen del PingPong

04-10-2008, 18:17

VDPX programming in BASIC

Edit: I also made a modification to the sprite engine. The SAT is no separate memory any more and is now cached from VRAM as well. This both made the sprite engine less complex and it will allow you to use the blitter on the SAT too

Umh, if the CPU write the sat, when you plan to cache the sat data? at vblank?

Por MagicBox

Master (198)

Imagen del MagicBox

04-10-2008, 18:37

The caching is done a couple scanlines before the first content scanline (Y=0). That means you have plenty time to update the SAT any time during drawing and in V-blank. The entire caching is fast though, the SAT and the current sprite patterns are cached in about 1 - 1.5 scanline.

Por PingPong

Prophet (3889)

Imagen del PingPong

04-10-2008, 18:59

The caching is done a couple scanlines before the first content scanline (Y=0). That means you have plenty time to update the SAT any time during drawing and in V-blank. The entire caching is fast though, the SAT and the current sprite patterns are cached in about 1 - 1.5 scanline.
Ah, OK.

For caching of the pattern do you mean that you cache the all sprite definition pattern of the unique sprite number from the 128 maximum sprites ?

(To clarify: you have 100 sprites on screen but all 100 are only using 5 different pattern n. -> does it mean that you only cache 5 patterns?)

GREAT.

Por wouter_

Champion (484)

Imagen del wouter_

04-10-2008, 20:40

Sprite Mode has been implemented in the Sprite Cores at no performance penalties ^^. Like described, the following modes are now supported:

00: 128 16x16
01:  64 16x32
10:  64 32x16
11:  32 32x32

Sprite X/Y flip continues to work on all sprite modes.

I'd like to suggest an alternative for these 4 fixed sprite modes: In the sprite attribute table, have one bit that
indicates "the coordinates of this sprite are relative to the coordinates of the previous sprite". This allows to chain an arbitrary number of sprites and in an arbitrary configuration. And you can still move the whole chain by only changing the coordinates of one sprite.

Though I'm not sure how well this would work in combination with the flip X/Y bits.

Por flyguille

Prophet (3028)

Imagen del flyguille

04-10-2008, 22:24

Sprite Mode has been implemented in the Sprite Cores at no performance penalties ^^. Like described, the following modes are now supported:

00: 128 16x16
01:  64 16x32
10:  64 32x16
11:  32 32x32

Sprite X/Y flip continues to work on all sprite modes.

I'd like to suggest an alternative for these 4 fixed sprite modes: In the sprite attribute table, have one bit that
indicates "the coordinates of this sprite are relative to the coordinates of the previous sprite". This allows to chain an arbitrary number of sprites and in an arbitrary configuration. And you can still move the whole chain by only changing the coordinates of one sprite.

Though I'm not sure how well this would work in combination with the flip X/Y bits.

mmm your idea is better... so, instead of have fixed chaining you can to have a BIT that indicates that the XY coord are not absolute, but are offsets of the XY FINAL RENDERED value of the sprite that is chained.... so, you can to do player on blocks of 2x8 chaining 16 sprites, thinks in STREET FIGHTER by example

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