[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Best API?

>>> I'd also like some color layering (transluscent
>>> sprite overlays)

>> I haven't done this, but I think it could be added fairly easily.

>Not sure of the most optimised method, but a bit of jigging with palette
>values based on the sprite to overlay would probably do something close...

If you don't have RGB, and you're in a palette mode, allocate a 256x256xN lookup
table. N gives you the number of fade layers. This works really well, because
you can also specify some colours as more opaque than others. I also used to use
brighten and darken colours, where the effect was to add or subtract light from
the colour they were put on. You can also have lines that do things like remove
the colour and leave just the greyscale information. All with the same sprite
code but using a different page from the look-up table. And it's fairly fast.

>>> <console only>
>> Same here.  You'll probably get a lot of flack for this though.
>Don't see why. Is everyone /really/ that desperate for X games?! I would
>have thought a performance hit would be incurred by running on top of X and
>considering the potential for badly optimised code in any of my efforts I'm
>gonna need all the spare cycles I can get! ;-)



X does not impose these massive overheads. By the time you're running MITSHM,
you might as well be in an SVGALIB system, but it actually works on most
machines instead of simply crashing them. I for one, will no longer run SVGALIB
games, simply because I'm fed up of them going "I'll have 640x480 please Bob"
without bothering to ask if the driver can do it and then I have to reboot. The
only time I find out if a game is 320x200 or 640x480 is after it crashes or not
and I don't find that acceptable. Even an "I'm about to start a video mode your
SVGALIB driver thinks you might have, or quit now" would be nice. But no.
Download it, untar it, start it, "twonk!!". No picture. Reboot.

X does practically damn nothing unless you ask it to. It's not Windows. It's not
sat there generating a billion events for you to throw away. That's what the
event mask is for. Every goes "X11 - big overhead" because when they look at top
it's using 80% CPU. Of course it frogging is, it's doing YOUR BLITTING FOR YOU.

Otherwise your game would be sat there at 80% CPU instead.

And if you're going to use SVGALIB, make it switchable. I can defocus an X11
game to use a database when an agent phones up to ask about something, most
SVGALIB games go "NO! Thou shalt not switch VC. Oh actually... TWONK!!" No
picture. Reboot.

>> This method would provide minimal sprite functionality.  Loading
>> sprites/colormaps, blitting transparent/solid sprites, clipping, etc...
>Potentially this would be fine. Certainly you have mentioned my immediate
>needs above. Anything else I'm fairly sure I could hack up directly
>(although it has been a while since I've done any GFX based coding...)

What's wrong with all the games libraries out there? Doesn't the one that was
used for Railroad Tycoon do that stuff? I mean surely, if it's suitable for
commercial stuff?