I miss a post of mine about libs and SVGA modes, I imagine it receveived an angry answer and both were "modereated"...
So I imagine I was not explaining my idea correctly. Excuse me, I'm just a little rude sometimes. So there is again.
I think one thing that slows the spreading of UGL is not UGL, is the tricky VESA standard.
If a programmer wants to use a 32 bits mode he/she must be warned that some computers only have 24 bit modes (that UGL does'nt handle) and in some resolutions he/she can have only 16 or maybe 15 bits, because of the memory. This requires designing a complicated mode selection routine that needs testing in a lot of computers for different video cards.
So I think UGL should offer that king of function. This way programmer could select a resolution and a mode (True/hicolor or 8bit-paletted) and the library itself would select the best available bit depth. This poses a problem with sprites, which would need a byte-depth conversion at loading. This would make starting with UGL easier.
A similar function exists on Allegro, it has puzzled some people to blame UGL for not being able to set Voodoo cards to 320X240, as Allegro does. In fact Voodoo cards don't have a 320x240 mode in SVGA, Alegro is just using a X-Mode without warning the user...
well, it's nice to see a suggestion for UGL's improvement rather than blasting at it for no logical reason, but this maneuver sounds tricky. allow me to explain:
allegro has separate blitting routines for mode x, because 320x240x8 is planear. so for ugl to work in this mode, it has to create a separate off-screen buffer that doesnt use video memory, a *very* tricky maneuver, (or duplicate all of its graphical routines, which is just too much work).
however, switching to a 32-bit mode where 24-bit is unsupported is a very good idea.
Well, I see my example was the worst one I could choose. I tried to show how a library makes easy what's tricky and confuse. Off course I was not suggesting UGL should implement Xmodes, they are completely obsolete...
UGL makes the use of EMS,XMS, resources very easy. My feeling is it should do the bit depth selection by itself .The user should have just two options:paletted or True-Hicolor).
Edited;
It's not very funny for a newbie posting in this forum "Im making a super game in 640X480X32, how can I do the collision detection (for example)" and have an answer by us old curmudgeons saying "Besids collision detection, be warned that not all cards have a 640X480X32 mode"... Very frustrating
that makes sense. another idea might be to just add a function that selects the highest support color depth available for a resolution. that wouldnt be too much work i suppose.
Hey antoni, well i dunno how much you've used the lib. You might notice that all the UGL examples use global constants for the bitdepth and resolution. This is so that you only have to change those constants to use another res/bitdepth. All the bitmaps that are loaded are automatically converted to that bithdepth as well. Of course, it doesn't have any dithering. But it is afterall a real mode lib which has to be very convservative with memory. Such things as letting it chose the best resolution/bitdepth is in our opnion something non time critical and and simple for the user to do. So this isn't anything that should be included in the lib. UGL gives you the means to do pretty much anything in a simple way. But it doesn't do everything for you. And that's the way we belive it should be. I think you'll notice that what your asking for will only take a few extra lines to add.
Hi, Blitz:
I like the library just as it is. An extraordinary library. In fact I have used it only to make a quick hack my jpeg viewer. But it will change soon...
Yes I can do myself the bit depth selection routine easily..maybe because I have been using SVGA modes since 1999, and I know how tricky they are. If the library made bit depth totally transparent to the user, SVGA modes would become as easy as SCREEN13, and you would have more customers.
Quote:I miss a post of mine about libs and SVGA modes, I imagine it receveived an angry answer and both were "modereated"...
Hi Antoni. I don't recall that post, but probably it was not moderated (if it was it wasn't me). A low number of posts are actually deleted here, and if there was a abusive response to your post, only the abusive post would have been erased and not your post.
There was a server change a while back that unexpectantly erased many posts. Maybe yours was one of those -- that sadly turned into recycled disk space.
- Dav
Hmm, you know C? You could do your jpeg loader for UGL in C. It's very simple. I've been wanting to make an online database for UGL addons for a long time. But i've to lazy and zext.net doesn't have SQL. And i refuse to use plain files for such a thing. Anyway, i've done a few addons myself in C. Using uglDCAccessXX you get a far pointer per scanline to a DC. No matter what type of DC. And the DC handle is a far pointer to a structure. In C you get direct access to this structure as well by declaring the "handle" as PDC (pointer to DC).
Here's an example of how to do addons. It's an alternative blitter. Never finished it though.
Code:
// ::::::::::
// name: ugluPutSprAlt
// desc: Draws the non masked area with a different color
//
// ::::::::::
void UGLAPI ugluPutSprAlt ( PDC dstDC, int x, int y, PDC srcDC, long col )
{
int xa, ya;
int lGap, tGap;
int lWdt, tHgt;
RECT recta, rectb;
FBUFF dstscnl, srcscnl;
unsigned char col8;
unsigned short col15, col16;
unsigned long col32;
//
// Has to have the same format
//
if ( dstDC == srcDC )
return;
if ( dstDC->fmt != srcDC->fmt )
return;
//
// Calculate the corners of the sprites
//
recta.x1 = x;
rectb.x1 = 0;
recta.y1 = y;
rectb.y1 = 0;
recta.x2 = x + srcDC->xRes-1;
rectb.x2 = 0 + dstDC->xRes-1;
recta.y2 = y + srcDC->yRes-1;
rectb.y2 = 0 + dstDC->yRes-1;
//
// Clip rectangle a against b
//
//
if ( recta.x1 >= rectb.x2 )
return;
else
{
if ( recta.x2 <= rectb.x1 )
return;
if ( recta.x1 < rectb.x1 )
lGap = rectb.x1 - recta.x1;
else
lGap = 0;
if ( recta.x2 > rectb.x2 )
lWdt = rectb.x2 - recta.x1 - lGap;
else
lWdt = recta.x2 - recta.x1 - lGap;
}
if ( recta.y1 >= rectb.y2 )
return;
else
{
if ( recta.y2 <= rectb.y1 )
return;
if ( recta.y1 < rectb.y1 )
tGap = rectb.y1 - recta.y1;
else
tGap = 0;
if ( recta.y2 > rectb.y2 )
tHgt = rectb.y2 - recta.y1 - tGap;
else
tHgt = recta.y2 - recta.y1 - tGap;
}
//
// Select the correct loop
//
switch ( srcDC->fmt )
{
case UGL_8BIT:
col8 = col;
for ( ya = 0; ya < tHgt; ya++ )
{
dstscnl = uglDCAccessWr( dstDC, ya+y );
srcscnl = uglDCAccessRd( srcDC, ya+tGap );
((FBUFF8)dstscnl) += x;
((FBUFF8)srcscnl) += lGap;
for ( xa = 0; xa < lWdt; xa++ )
if ( ((FBUFF8)srcscnl)[xa] != UGL_BPINK8 )
((FBUFF8)dstscnl)[xa] = col8;
}
break;
case UGL_15BIT:
col15 = col;
for ( ya = 0; ya < tHgt; ya++ )
{
dstscnl = uglDCAccessWr( dstDC, ya+y );
srcscnl = uglDCAccessRd( srcDC, ya+tGap );
((FBUFF15)dstscnl) += x;
((FBUFF15)srcscnl) += lGap;
for ( xa = 0; xa < lWdt; xa++ )
if ( ((FBUFF15)srcscnl)[xa] != UGL_BPINK15 )
((FBUFF15)dstscnl)[xa] = col15;
}
break;
case UGL_16BIT:
col16 = col;
for ( ya = 0; ya < tHgt; ya++ )
{
dstscnl = uglDCAccessWr( dstDC, ya+y );
srcscnl = uglDCAccessRd( srcDC, ya+tGap );
((FBUFF16)dstscnl) += x;
((FBUFF16)srcscnl) += lGap;
for ( xa = 0; xa < lWdt; xa++ )
if ( ((FBUFF16)srcscnl)[xa] != UGL_BPINK16 )
((FBUFF16)dstscnl)[xa] = col16;
}
break;
case UGL_32BIT:
col32 = col;
for ( ya = 0; ya < tHgt; ya++ )
{
dstscnl = uglDCAccessWr( dstDC, ya+y );
srcscnl = uglDCAccessRd( srcDC, ya+tGap );
((FBUFF32)dstscnl) += x;
((FBUFF32)srcscnl) += lGap;
for ( xa = 0; xa < lWdt; xa++ )
if ( ((FBUFF32)srcscnl)[xa] != UGL_BPINK32 )
((FBUFF32)dstscnl)[xa] = col32;
}
break;
}
}
Unfortunately my C is as bad as my english. I have just tried the language, I think i have a rotozoomer somewhere. But the jpeg viewer is a too serious project for my C. Moreover the viewer is outdated, it should be able to display progressive jpegs (the format digital cameras use).
Well I can't promise you nothing.. Which compiler are you using? Where can I find a 16 bit compiler?
I use either borland c++ 5 or watcom, both suck but you won't find any better ones.