The project was posted at http://www.ultrano.com/ilix/ some time ago - it's just that the documentation is incomplete. But the sourcecode is written in the best asm style I've ever had - finally professional :) . After finishing Ilix, I ported parts of it to C (for PalmOS) - and the results are really cool:
Before:

After:

:-D

>> includes a bunch of non DX yet gamedev related code
Yes, Ilix provides all functions I've ever needed in 2D games, a really quick start from scratch, tools to compress and include your .bmp or .tga images.
I know just a few people might need it - most game developers moved to 3D, but it's nothing to disappoint me, because Ilix's main purpose is for MDI apps :) .

The engine is in a .lib file, 15kB :)
Posted on 2005-02-23 08:55:23 by Ultrano
OK,

ALL demos draw rubbish on my screen on Win2k with a Geforce2 MX 64M video card...

It looks like a pitch or color format very wrong assumption somewhere in that engine :D
Posted on 2005-02-23 14:40:46 by BogdanOntanu
interesting, they run fine on my second PC (with GeForce2 32MB). I was experiencing garbage on my ATI because I hadn't set the color masks - the GeForce seemed not to care about color masks back then either. I'll have to investigate, I'll test on another MX 400 64MB :|
Could you post or send me an email with a 100x100 screenshot of the garbage, please? I use DDraw1 ^^" , so this could be the reason too.
Posted on 2005-02-23 14:54:30 by Ultrano
I do not think it is Directdraw1's fault, i have been using DD1 for HE for quite a while before moving to DX6.1 for some minor extra features, so i know that DD1 works just fine.

Aparently it is a Pitch versus Width issue.
On aseccond thought it also looks like the colors are wrong so it might be that you try to setup a fixed color mode :D

Welocome to hell:
-some boards will only accept 24 bits
-some boards will only accept 32 bits
-some boards will accept both
-some boards will accept none (aka only 16bits)

So, if you are targeting truecolor only you must provide routines for both 24bits and 32 bits :D and assume your 2D engine will not work on some older boards like Voodoo2-3

I will take some screenshots and send them to you...
Allready did that ...but what is your email address :-?

Nevermind i have placed them on:
www.hostileencounter.com/ILIX_screenshots.zip

Eh, and basically without the initialization stuff for a 2D engine using DirectDraw and doing alphablending in software one only needs 3 functions from DD:
1)Surface::Lock,
2)Surface::UnLock
and eventually
3)::Blt (not always)

So making a huge warapper arround this just "to make it easyer" is an overkill IMHO... but anyway i do appreciate the effort :D

PS:
----
(about your TODO list)
Make yourself a favour and do not read from video memory backbuffer "to make alpha blending faster" it will only make it slower ;) IF you want to use alpha blending then you need to have a backbuffer in system ram.
Posted on 2005-02-23 19:56:15 by BogdanOntanu
Hrm, afaik voodoo3 supports 32bit color mode fine, although only in 2D? Can't remember if voodoo2 supports only 24bit mode, though.
Posted on 2005-02-23 22:13:58 by f0dder
I have just tested on an Voodo3 and it will only accept 24bits truecolor modes and only as a LFB. Aparently Windows drivers will simulate 32bits mode just to make the user feel safe ;)

However even so the hardware acceleration is cut OFF in 24bits mode and is only functional in 16bits modes :D

I can not find a Voodo2 arround anymore for testing :(
Posted on 2005-02-24 07:13:21 by BogdanOntanu
Hmm, interesting. Is 2D hardware acceleration also cut off in >16bit modes? When I used a voodoo3 for windows, it certainly felt faster than an unaccelerated mode that had 32->24bpp conversion... perhaps it's just the VESA modes that are limited, and native drivers do better?
Posted on 2005-02-24 10:28:43 by f0dder
I'll just do like in most software I've seen - create buffers in the card's default pixelformat, and then do custom blending with obeying the pixeldepth, and with having images with alpha channel reconverted from the current 16-bit to the new format on load/restore.

This huge wrapper is not an overkill, for this one I'm sure. The advanced clipping, using only one proc for blitting any type of image, including and loading all your sprites with just two lines of code, starting up a new project with 4 lines of code, automatic restore of lost surfaces (and the bitmap that was there), and several misc stuff - I refuse to work on a 2D project without any of these features. Unmanaged code that can break at any moment (resolution change for instance here) is bad for big projects, imho. So, I don't feel any regret for having spent some effort on Ilix :) - it just needs another push :-D



(about your TODO list)
Make yourself a favour and do not read from video memory backbuffer "to make alpha blending faster" it will only make it slower Wink IF you want to use alpha blending then you need to have a backbuffer in system ram.

In todo.txt I mean this:
1) have lpSurf1 - a 256x256 surface in sysram
2) lpBackBuffer - the backbuffer in videoram or sysram (will benchmark)
3) lpSomeAlphaSprite - this one is allocated with HeapAlloc, has alpha channel
; now the actions to do when copying lpSomeAlphaSprite over lpBackBuffer:
; assume we want to blt a 40x40px square part
1) copy with a ->Blt a 40x40 rect from lpBackBuffer onto lpSurf1
2) lock lpSurf1
3) mix the lpSomeAlphaSprite colordata over lpSurf1
4) unlock lpSurf1
5) async blt from lpSurf1 to lpBackBuffer

We can have an array of lpSurf1-like surfaces, to rotate which one we should use on the next AlphaBlt - in order to get fewer stalls.


Btw, having seen now the performance of many alpha-effects on my other PC (with the GeForce2), I think I'll pass using alpha in MDI apps ^^". At least, Street Fighter Alpha3 looks awesome with the fake alphaeffect (half of the pixels are transparent) :)
Posted on 2005-02-24 11:04:40 by Ultrano
Hi, I'm coming into this late so apologies if this is my misunderstanding.

In todo.txt I mean this:
1) have lpSurf1 - a 256x256 surface in sysram
2) lpBackBuffer - the backbuffer in videoram or sysram (will benchmark)
3) lpSomeAlphaSprite - this one is allocated with HeapAlloc, has alpha channel
; now the actions to do when copying lpSomeAlphaSprite over lpBackBuffer:
; assume we want to blt a 40x40px square part
1) copy with a ->Blt a 40x40 rect from lpBackBuffer onto lpSurf1
2) lock lpSurf1
3) mix the lpSomeAlphaSprite colordata over lpSurf1
4) unlock lpSurf1
5) async blt from lpSurf1 to lpBackBuffer


This process doesn't make sense to me, unless you are specifically trying to get round an unsupported driver/gfx card feature issue. There are far faster/better ways to blend. You're also risking a lock of the backbuffer, and unless your final blit (5) is hardware then it's not asynchronous. Can I ask why you're avoiding shaders or stages?
Posted on 2005-02-25 19:45:32 by defbase
I actually have virtually no experience in D3D or OpenGL ^^". I've only done 3D drawing with my own software engine for PalmOS (and now also ported it easily to Win32 with major help of Ilix). And also I had made one version of Ilix to use only DX9 - but it was sloppy for MDI since I used that VBuffer lock. Right now there are only two things I think I should do -
1) see how fast the DXSprite is on PCs I'm targeting
2) make Ilix use screen bitdepth, not 16-bit.

I was so hoping to have 16-bit bitmaps everywhere, so that I could do fast custom drawing, it's shocking to me a GF2MX400 can't do what my GF2MX200 does easily... I'd say it's a driver problem if it wasn't someone like Bogdan to report this :(

I am thinking of splitting Ilix in two parts- one dedicated for MDI, and one for games. I'll actually decide what to do when I have enough knowledge and experience with all this hardware acceleration. I'm newbie in this, I already see, so it'll take time :| . And I still have a game to finish for my primary job ^^" , not to mention the projects and responsibilities that are about to multiply after that. :o

About the "todo.txt" : I certainly have wrong assumptions about hardware acceleration, so it seemed to me this algorithm might gain some speed . :stupid:
In the end I might give up the project ^^" Or just dedicate it for my professional needs
Posted on 2005-02-25 20:55:39 by Ultrano