Tile sprite on ram and recall them.

[gekido_ken]

Hi guys!
Information on creating software sprites.
I designed these sprite tiles with the charset for the idea of ​​a game that I would like to create.
Is it possible to save these sprite tiles on a memory area and then recall them at the moment without manually redrawing them each time in XB256 or RXB?

 

Thanks

 

[+9640News]

I'm no XB256 or RXB guru, but I thought RXB at least had a VDP block move type command. With the presumption that is the case, it would be simply a single command to copy from one memory location to another to change the current character set definition you have for your existing need. It would probably be wise to have those characters in hexadecimal order such as ABCDEF......, rather than AcQRs...... where they are not contiguous and would require multiple calls.

 

Another thought would be to use a Call Link routine with the embedded video move commands. I do not know what the overhead is, but I think this could possibly be faster as you could possibly code multiple MOVB instructions precisely of the length needed without decrementing a counter and be possibly faster.

 

Something like the following:

 

MOVB @SPRITE1+0,@VIDEOPORT

MOVB @SPRITE1+1,@VIDEOPORT

MOVB @SPRITE1+2,@VIDEOPORT

MOVB @SPRITE1+3,@VIDEOPORT

etc

 

That would be quicker than:

 

LI R0,4

LI R1,SPRITE

REPEAT

MOVB *R1+,@VIDEPORT

DEC R0

JNE REPEAT

 

I hope that make sense. Again, not sure of the overhead to use a call link to know whether the CALL LINK route or RXB's video move calls would be faster, etc.

 

Beery

[+adamantyr]

I presume, as you mention "software sprite", you mean that you used characters to create these?

 

I am not familiar enough with either XB256 or RXB to comment on their capabilities in this area, but what you describe is a pattern mapping, right? You want to quickly blast out the character patterns at different positions on the screen?

 

Unfortunately, there's no "direct memory" work you can really do here to achieve this in XB or most flavors of it. Part of the problem is I presume you want to have a "transparent" block which will just skip and show the background. Different character patterns CAN be drawn relatively quickly by using DISPLAY AT, but having done this myself in an early version of Wizard's Doom, I can assure you it won't be fast enough for an action game.

 

What IS possible in XB, though, is to write an assembly language routine to do the work for you. I wrote routines to draw the 3D maze portion of Wizard's Doom quickly on screen and it worked pretty well. This is a similar operation; each different frame of your karate guy can be stored as a number value, and a LINK that just passes a starting position and the frame ID would then be able to draw the pattern out.

[jrhodes]

A little off topic perhaps, but judging by the sprites in the picture, is this planned to be a stage based beat 'em up (i.e. streets of rage), or more of a 1 vs 1 fighting game (i.e. mortal kombat)?

Edited May 21, 2019 by jrhodes

[gekido_ken]

I know that with XB256 it is possible to write and read in the VDP, in addition to being able to compress the graphics in a table, but I would need an example to understand how to do it.

[+9640News]

I'm not sure you want to uncompress a graphic if you are looking for speed for each time you change the graphic if speed is critical. That will take quite a few CPU cycles that may be spent better elsewhere. Just saying.

 

Beery

[LASooner]

I assume you want to redefine the same characters for each movement?

 

So the characters don't have to be redrawn just redefined?

 

I would set up the first set of characters in Magellan, Export for XB256, then add

CALL COMPRESS(1)

Just before the call key statement, then merge the COMPRESS program from the XBGD package and run it

 

select

6 - SCREEN2 CHAR PATTERNS

Select only the range of characters you want to save, they should be sequential. Save the merge file and remember the line # for that character set

 

Repeat for all the other movements, giving each one a different line# that won't overwrite the previous ones. For example let's assume each "sprite" is separated by a hundred, so the first data statement is at 1000, then 1100, 1200, 1300, 1400. The last line of each "sprite" data set is a ""

 

So in game you would, merge all the data statements into your base program, then draw the characters on screen,

 

Then in your game to redefine a character set you would set your restore point to whichever data represents what you want to do

 

This is the subroutine I would use in TIdBit

_STAND: RESTORE 1000 :: GOTO _READDATA
_BLOCKHIGH: RESTORE 1100 :: GOTO _READDATA
_BLOCKLOW: RESTORE 1200 :: GOTO _READDATA
_PUNCH: RESTORE 1300 :: GOTO _READDATA
_KICK: RESTORE 1400 :: GOTO _READDATA

_READDATA: 		READ A$ :: IF A$="" THEN _READDATADONE :: CALL LINK("CWRITE",A$) :: GOTO _READDATA
_READDATADONE: 		RETURN

CALL LINK("CWRITE",A$) Is what puts the character definitions into VDP

 

There are obviously some optimizations you could make because your head never changes, and for 3 moves the legs are the same, and the 2 others are similar.

 

I hope this is clear, I've done it so much it sounds clear in my head.