GP32 Rle Sprites


JyCet

Member
Joined
Feb 23, 2004
Messages
469
Age
118
Location
France
Website
Visit site
I know with RLE Sprites i can increase speed of game , but today i dont know how it work and how implement it on GP.

Does someone use this function ? I think yes :) but who and how ? :(

thk in advance.

JyCet.
 
Well, typing "rle sprites" into google gave lots of hits, and sample code etc. But if you can't operate google, I don't like your chances of programming sprites :(
 
With the same effort you spend doing RLE Sprites you can easily come up with Compiled Sprites, which are _really_ fast stuff <_< I think I have some examples online..
 
Although it is really a case of horses for courses.

Drawing non-transparent tiles will probably not be much faster (possibly slower?) than using standard SDK routines.

Also to use compiled sprites (or see any real speed benefit from RLE sprites) you will need to code the routines in assembly.

So it's a case of really making sure that you need some extra speed in sprite drawing and whether the type of sprites you're using will suit these methods (ie high transparency).

:)

@Mr Spiv
Have you actually got a Bitmap->Arm compiler for GP32?
Cheers
 
Dave18 posted on Feb 24 2004 at 10:01 AM said:
@Mr Spiv
Have you actually got a Bitmap->Arm compiler for GP32?
Cheers
Sure.. it's there.. cspr.tgz or something. If I remember right there are both bitmap to ARM and bitmap to Thumb "compilers". Check it out.. I pushed easily 3400 16x16 256 colors sprites @ 50fps with that. The code was meant for a tile engine that never materialized though :(
 
Last edited by a moderator:
I may have completely misinterpreted this post, but why would drawing run length encoded sprites be faster than blitting a bitmap sprite to the screen?
 
ok, that makes sense, but what about clipping the sprite? The Y clip would be relatively easy, but the x clip would require an extra if per line of colour you want to draw right?
 
just a sec, reading this on the clipping:

http://www.nondot.org/~sabre/graphpro/sprite6.html

... and I've found out that I was basically right about the clipping being a bit of a pain in the x axis.

I found this an interesting topic because I am currently implementing RLE sprites myself, but for memory size purposes rather than speed and I was surprised to read that there were faster too. Although, I am going for 16 colour sprites, using 4 bits for the colour and 4 bits for the number of pixels. Although I have added the ability to put special flags in the sprite which tells you to swap the palette, so allowing up to 31 colours. There are also a few other flags that make the file a little smaller. I have been trying it on MUGEN sprites, which use the PCX format, and on average I halve the size of a sprite with no noticable visual difference. Obviously the flags slow down the drawing a bit

my routines are also slow because they are coded in C, having never touched asm before, has anyone got some asm sites they can reccomend? (Obviously for the ARM 9).

Cheers,
 
Mr Spiv you forget i'm a begginer in C. :p
I've read your source sample but you use lot of lcd hack in the same demo.
So it's very difficulte for me to undertand your very impressive demo.

Today i use the standart gamepark GFX function for the sprite but i know it's possible to increase the speed of display.

I dont need triple buffer, 8bit transparency, flipping ... just 2 basic function :huh:
one to change this one:
GpTransBlt(NULL,&gpDraw[nflip],x,y,screen_x_size,screen_y_size,(unsigned char*)sprite,x_start,y_start,x_size,y_size,transparency_index_color);
and a second to change
GpBitBlt(NULL,&gpDraw[nflip],x,y,screen_x_size,screen_y_size,(unsigned char*)sprite,x_start,y_start,x_size,y_size);
 
JyCet posted on Feb 24 2004 at 06:06 PM said:
Mr Spiv you forget i'm a begginer in C. :p
Hah! I've seen your stuff.. you are far from a beginner <_<
 
Last edited by a moderator:
There's also another option worht checking out - BC sprites (BC= Bit Coded Sprites)


in order here are the features

Sprites - Usually the slowest

RLE Sprites - Save on memory - can be slow to render

BC Sprites - Save on memory, can be Ultra fast

Compiled sprites - Ultra Fast - but can use lots of memory upto 8x memory of a normal sprite!!
 
Yo ZJ !


2 the others:
and if u have some of free RAM
just keep both: RLE + common sprites... of the same object..
and choose the one u need...

and do profile your code on the real HW...
and optimize it step by step

g'luck!
 
ZardozJones posted on Feb 25 2004 at 11:37 AM said:
There's also another option worht checking out - BC sprites (BC= Bit Coded Sprites)
What's that? I had some thoughts long ago using bitmasks to mark pixels to set and in that way do "fast" lookup & selection of correct drawing routine.. but this isn't anything like that, is it? :blink: You would only need to store pixels that are not transparent...
 
Last edited by a moderator:
hehe BC Sprites work like this:

say you have a 16x16 16bit sprite

you have a 16bit data[]

the very first piece of data is a bit mask for a horizontal line

where each bit dictates which pixel is non transparent and thus dictates how much data follows

e.g.

03,0xff00,0xff00,01,0xffff

would mean:

0 1 2 3 4 5 6 7 8 9 a b c d e f
ff00ff00
fffff

simple stuff - and very quick to decode
in fact you can use a jump table to decode each line


in the case of 16x16 you split the decode table up into 2 lots of 8bit masks

even tho you get alot of jumping around it's still quite fast once the cache kicks in
 
Yeh.. just what I thought of ;) I sketched something.. and this would produce pretty kick ass asm implementation.
 
Back
Top