1. Sprites
- Posted by DHarte at AOL.COM
Jul 11, 1998
How do you put sprites on the screen in SVGA modes without destroying the
background (with color 0 being transparent)? The only way that I could figure
out was to check the color of each pixel in the image, and write the nonzero
pixels to the screen. This works, but is much too slow.
Thanks in advance.
Abraham Harte
2. Re: Sprites
>How do you put sprites on the screen in SVGA modes without destroying the
>background (with color 0 being transparent)? The only way that I could
figure
>out was to check the color of each pixel in the image, and write the
nonzero
>pixels to the screen. This works, but is much too slow.
>Thanks in advance.
Split the sprite up in pieces of horizontal lines and store the complete
offset of every set of those lines. The use pixel to display every set. If
you want to poke () and do the bank-switches yourself, you're better off
replacing the {x,y} position wiht a fixed calculated position, an offset to
add to the begin offset in memory.
This is the theory behind the compiled sprites in my GFX.
Here I remade a simplified version of those routines:
function make_cs (sequence pic, index trans_color)
sequence ret
index pos, prev
ret = {}
for index = 1 to length(pic) do
prev = 0
pos = find (trans_color, pic[index])
while pos do
ret = append(ret, {{prev, index}, pic[index][1..pos-1]
if not length(ret[length(ret)][2]) then
ret = ret[1..length(ret)-1]
end if
prev = pos
pos = find (trans_color, pic[index][pos+1..length(pic[index])]
end while
if length(pic[index]) then
ret = append (ret, {{prev, index},pic[index]})
end if
return ret
end function
procedure display_cs (sequence cs, sequence pos)
sequence item
for index = 1 to length(cs) do
item = cs[index]
pixel (cs[1]+pos, cs[2])
end for
end procedure
See, the best optimization trick in games and most other stuff is to see
when we calculate something or make a decision.. always ask youself : Can
this calculation, decision or part of this decision be made fewer times ?
Like calculating an offset, you only need to do this when a position
changes, _not_ everytime you want to draw a sprite, etc.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
3. Re: Sprites
Ralf said:
>Split the sprite up in pieces of horizontal lines and store the
complete
>offset of every set of those lines. The use pixel to display every set.
If
>you want to poke () and do the bank-switches yourself, you're better
off
>replacing the {x,y} position wiht a fixed calculated position, an
offset to
>add to the begin offset in memory.
>
>This is the theory behind the compiled sprites in my GFX.
>Here I remade a simplified version of those routines:
<SNIPPED STUFF>
>Ralf Nieuwenhuijsen
>nieuwen at xs4all.nl
That's not at all the way I do it and my way seems pretty fast:
Somebody (I can't remember whom) posted to the recent users contribution
page a certain "bitmap.e" which does stuff like extract a bitmap from a
larger bitmap given UL and LR points and insert a smaller bitmap into a
larger one.
Once you cut a peice (bm) out of the background the same size as your
sprite do something like this
temp = (sprite = 0)
temp = bm * temp
temp = temp + sprite
temp now contains the sprite with the background showing through where
the sprite is zero. you can now INSERT temp into the background where
you extracted bm from. Or at least show it that way on the screen.
I'm sure Ralf's way is good but this seems much simpler to me
Will whoever made "bitmap.e" please explain this better and take credit
for this cool set of routines.
Sincerely,
Lewis Townsend
|\ ____ _ _ _ _ __
| \ | __/ || / | // || / __ \
| \ ||_ || //|| // || ||__\|
| \ | _| || // || // || \___ \
| |\ \ ||__ ||// ||// || |\__||
| | \ \|___\ |_/ |_/ || \____/
| | \ \ _____ _______
| | \ \ | __ \ | _ _ |
| | \ \ ||__|| |/ | | \|
| | \ \ | __ / | |
| |______\ \ || \\ | |
|___________\ || || |_|
Keroltarr at hotmail.com
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
4. Re: Sprites
>That's not at all the way I do it and my way seems pretty fast:
Well, if you want it simple and fast (also for non-pentiums I mean,
multi-sequence multiplications as you do.. are slow) you might want to
consider, the technique used by Jiri..
Its still in the archive.
Which method is faster depends on the type of sprite.
An image with a lot of see-though holes in it, will be faster with his
method.
An image like a bal or with a few holes in it, will be faster with my
method.
And you were talking about easy to implent.. I included the routines in the
mail.. how easy can it get 
?
(Yes, I too, can be objective at times.. even with Jiri's code
However, Ememcopy, a nice machine code routine that uses the command list
technique can also do the SVGA nowadays. Its updated, and it does the
banking for ya.. I assume)
However be warned mixing it together with euphoria pixel () routines, cuz
they seem to expect the bank to be reset to zero.
If you just want to get a higher resolution that the lacking 320*200, try
the ModeX routines of Pete. They are also updated now. And you can tweak the
resolution to 500*400 if i'm not mistaking.
BTW Unreal runs almost as fast in the weird resolution of 538 * 382 (or
something near this)
I havent figured out why yet, but any resolution higher cuz notibly slower.
Maybe some1 knows how to tweak into that video mode ? Maybe it got something
todo with MMX though. (the video mode was 16-bpp btw)
Any one know about this ?
Ralf
5. Sprites
Hi to all, I need some help to solve problems with my sprites library.
In my demo, the sprite moves in the screen, but he appears to '"blink",
may it be result of something about refresh rate ?
The file is attached in UUEncode format.
If someone could help me, I'll like.
Thank you
Eduardo Uemura Okada
e-mail: cool at mii.nutecnet.com.br
