new GFX card

Page 16/20
9 | 10 | 11 | 12 | 13 | 14 | 15 | | 17 | 18 | 19 | 20

By PingPong

Prophet (3833)

PingPong's picture

26-09-2008, 20:40

Effectively, with a large number of sprites patterns, flipping is less important. At least some pattern could be blitted from main memory. in the vdpx environment z80 is almost free.. That's a very good thingSmile

By MagicBox

Master (198)

MagicBox's picture

26-09-2008, 23:03

I'll keep the flipping in mind though. I will modify the engine to have 64 attribute bits per sprite and see how that would perform. If that doesn't cost any speed I'll just do that and rearrange the registers in such way that you hardly have to read-mask-modify-write attribute fields. (keeping visible and collision in one byte, keeping X highbit separate in a byte, keeping pattern high-bits separate in a byte too etc)

By ARTRAG

Enlighted (6681)

ARTRAG's picture

27-09-2008, 00:24

Can you have a status bit that says if the sprite is colliding ?
The cpu can scan the SAT reading attributes to know if a sprite collided with something...

By MagicBox

Master (198)

MagicBox's picture

27-09-2008, 10:28

I think that will be possible. However, the status bit won't be in the SAT then. There will be a collision status register instead which is valid after each frame. Keep reading it to get the index of the sprite that collided untill you read &HFF from it (indicating end of collision list) For VDPX, the SAT is read-only to be able to achieve this superior processing speed of 128 sprites per pixel clock.

The SAT does not reside in normal VRAM. It is a dual-port internal RAM of 512 bytes in the FPGA itself. The CPU writes to it, the VDPX reads from it for processing. This internal RAM runs at 200MHz. Then I have a 512 bytes mirror ram of which the read-port goes to Z80, so Z80 can just read the SAT like normal.

If enabled, the VDPX is accessible through a 16KB slot page. Just like the memory mapper, VDPX will have a page select register. 0 - 31 for any of the VRAM pages, however page 32 maps the SAT and Palette table into the slotpage. (All of the memories will be made accessible with IN/OUT as well using read/write pointers)

Edit: If I am to implement this collision status register, the Collision Enable attribute for a sprite would become obsolete since the collision list would be filled with colliding sprite indices anyways. Or keep the bit where the collision list only gets filled by sprites colliding with a sprite whose CE bit is set (including this sprite itself) In addition you'd get a Sprite Collision interrupt bit in the interrupt register which will be set if the collision list is filled after a frame, together with the vertical blank interrupt.

Would that be a useful collision reporting?

By MsxKun

Paragon (1039)

MsxKun's picture

27-09-2008, 12:59

All this sounds really great. Hope we can see it working on our MSX soon! Big smile

By PingPong

Prophet (3833)

PingPong's picture

27-09-2008, 13:45

@MagicBox: remember that higher is the SAT, higher is the time needed to write it from CPU.
About collision, think about this:
having 3 bits of sprite category could be a good solution tradeoff.
LEt's me explain: in vintage games tipically you have two/three categories of sprites:
1) main charather
2) enemy (including also projectile from any enemy)
3) main charather weapon's

Usually,it it useless to know if an enemy collided with another enemy-

What we need to know is if:

A) enemy collided with main charater
B) main charater weapon's collided with some enemy

if i assign to every enemy a bit pattern like 001, then to the main charater the pattern 010, then to the weapon the pattern 100, AND the VDPX stores in a unique register the logical or of the patterns where it reveal a collision i can have:

011 -> main charater collided with enemy
101 -> weapon collided with enemy
....

Of course defining the effective sprite that collided with the other should be done by CPU, but this cuts down the CPU time.

By Leo

Paragon (1236)

Leo's picture

27-09-2008, 20:53

ideally vdp could be emulated using newer hardware like russian did on aleste 520ex :
aleste520.narod.ru/html/vdp_emulator.html

By MagicBox

Master (198)

MagicBox's picture

27-09-2008, 22:40

@PingPong
I'll think about such collision system, I get the idea.

@Leo: VDPX will not need to emulate the existing VDP. It will not be replacing it. The idea is that VDPX gets a video-in port which takes the existing MSX video out (through scart). When software activates VDPX, it switches video signal from standard MSX video out to VDPX out.

By Metalion

Paragon (1454)

Metalion's picture

27-09-2008, 22:48

ideally vdp could be emulated using newer hardware like russian did on aleste 520ex :
aleste520.narod.ru/html/vdp_emulator.html

Maybe it's too late, or maybe I've been drinking too much (actually I did), but I don't understand a thing about what those guys have been trying to do ... Could someone explain it to me ? :P:P

By PingPong

Prophet (3833)

PingPong's picture

27-09-2008, 23:52

ideally vdp could be emulated using newer hardware like russian did on aleste 520ex :
aleste520.narod.ru/html/vdp_emulator.html

Why emulate? the old vdp is still there. And the main reason to have VDPX is to replace the old one for new games....

:D

Page 16/20
9 | 10 | 11 | 12 | 13 | 14 | 15 | | 17 | 18 | 19 | 20