Similar to my previous 2D engines ILIX (opensource/free) and iDraw (inhouse commercial), but relies completely on the CPU. Thus, is very fast at drawing some specific complex graphics (much faster than DirectDraw/D3D), but is a bit slower at raw Blt.

Alphablending, additive blending, custom blends, ROP drawing - this is the target, 50% complete.

Uses a GDI DIB for output, the internal drawing and clipping is custom.

Current version: 0.4 , major-build-version:02
To add:
- more blending ops and drawing ROPs
- implement clippers: sdEnterClip(x,y,wid,hei), sdLeaveClip(), sdAdjustDrawOffset, sdForceClipper(wid,hei)
- load compressed images (with alpha-channel)
- load jpg/gif/png without alpha-channel
- documentation

The sDraw.exe is a demo of the blending and speed of sDraw, forced to update at 50fps. Takes less than 1% cpu here :D

: the attachment is in one of my next post in this thread
Posted on 2006-06-30 17:06:44 by Ultrano
I'll definately look into this for my 2d Development, but I have to say that you must have a nice PC, since it took 46 to 52 % of my processor (a p3 866). In any case it'll probably run quite nice considering that WAS forced to 50 FPS.
Posted on 2006-07-01 15:29:32 by Bobbias
Hmm, what's your videocard? And the screen width/height/bpp

My PC isn't a beast, relatively, but I'm very pleased with it:
Sempron 2200+
512MB DDR400,  bandwidth: 2.7GB/s
Radeon 9200SE
1024x768, 32bpp
GDI's BitBlt is hardware-accelerated (good drivers here ^^ )

I had a p3 700Mhz some time ago, I was always angry at its awful performance - its memory interface sucked (mobo+RAM's fault partially), happily gave it away with the mobo, RAM and case.


sDraw, isn't good/dedicated for games, I should warn you :) . But still, the blending functions can be a turning point in your decision.
For nowaday 2D/3D games, I would recommend Direct3D9, but it will be too much for a newcomer into gamedevelopment.

I've finished sDraw to the point that I can use it for my purposes, what's left for a public release is:
1) make independent from my code-base (something like the MASM32 package)
2) documentation, but will be in C-style mostly
3) examples in asm, C, VB
Posted on 2006-07-01 22:07:17 by Ultrano
Well, I'm running an Nvidia GeFroce FX 5600 (256 MB vid ram) underclocked VERY slightly (it was overheating :/)
P3 866MHz
384 MB ram (no idea on the specs of the ram)
1280x1024, 32 bpp

And in any case, I think that for the basic games I'd be making, sDraw is probably good enough. And I used to know a little about working in DX, but not any more, they've released way too many versions, that my knowledge fell behind, and now I need to relearn DX somewhat.
Posted on 2006-07-02 02:42:46 by Bobbias
uses 0-1% cpu usage on my 3200 athlon xp-ati 9250

nice! 8)
Posted on 2006-07-02 10:12:26 by asmrixstar
Almost finished and polished it up, toyed a bit to make 2 example-apps.
Now, sDraw is independent from my SDK, there are both .lib and .dll versions.

The sdDeleteSprite() proc is buggy now, crashes - will fix it sometime. You needn't use it anyway.


The Documentation will come last, I guess ^^"

Final attachment in final post
Posted on 2006-07-02 16:43:14 by Ultrano
nice work, thx for sharing
Posted on 2006-07-02 17:04:41 by asmrixstar
Hi, Ultrano
(much faster than DirectDraw/D3D), but is a bit slower at raw Blt.

How can it be faster than the hardware? Which version of direct3d are you reffering to? DDraw7 is dead-slow because of its design. What operations exactly are faster?

BTW: It's using ~25% of my Pentium4 2.4GHz, GF FX 5200, 1GB RAM


And I used to know a little about working in DX, but not any more, they've released way too many versions, that my knowledge fell behind, and now I need to relearn DX somewhat.

Hi Bobbias. Learn Direct3d 9.0c and (any) newer. Nothing else! ;)
Posted on 2006-07-02 22:06:29 by ti_mo_n
Well, if I'm just writing something that doesn't require massive graphics libraries, and isn't exactly complicated (a la pong) I should be able to write it using GDI or something like sDraw.

Also, as a side note, anyone know what the comperative speeds between D3D (9.0c) and OpenGL are? (I guess it's got a lot to do with your card, but if you know someplace that has info like that, I'd liek to see it)
Posted on 2006-07-02 23:20:49 by Bobbias
ti_mo_n , in this case vga hardware is slower:
the triangular data usually is rather random, here it was auto-generated just for a test. This was done with DirectDraw - 23fps and no alpha-effects aren't enough for me.
The idea is that "mov ,eax" is faster than sending the individual pixels to the VGA :)
Happy ATi user here ^_^
Attachments:
Posted on 2006-07-03 03:29:40 by Ultrano
version 1.0 finally ready (documentation took 2 days)  ;)
Features and stuff ... read it all in the .chm :)



Posted on 2006-07-03 12:34:31 by Ultrano
I'm getting a You are not allowed to access this section when trying to download the sdraw06.zip attachment :-s

EDIT: doh, that explains it :)
Posted on 2006-07-03 12:51:46 by f0dder
Version 1.1:
- added drawing of arbitrary lines with subpixel accuracy (but no antialiasing)
- added some simple sDrawRectXXX funcs
- font loading and text-drawing! (fonts are embedded as compressed 8bpp bitmaps)

The documentation has info on the new procs, but I didn't make any example. Well, I attached a screenshot of my usage of sDraw in a commercial app of mine. There the "Automation Editor" window is completely drawn with sDraw, all other windows are drawn with DirectDraw.
Posted on 2006-07-15 21:41:12 by Ultrano

Version 1.1:
- added drawing of arbitrary lines with subpixel accuracy (but no antialiasing)
- added some simple sDrawRectXXX funcs
- font loading and text-drawing! (fonts are embedded as compressed 8bpp bitmaps)

The documentation has info on the new procs, but I didn't make any example. Well, I attached a screenshot of my usage of sDraw in a commercial app of mine. There the "Automation Editor" window is completely drawn with sDraw, all other windows are drawn with DirectDraw.

I have some code that in parallel draws several pixels after conversion from SSE, as I scale it anyway from 1.0f range to 255 integer range, wouldnt it be easy to add fullscreen antialiasing while copying from backbuffer with scale neighbouring pixels differently while get advantage of better bandwidth with movq /movdqa?
whats the difference between antialiasing and SAIx2 ?because this will become similar to SAIx2 smoothening

Posted on 2006-07-15 23:04:58 by daydreamer
sDraw is designed exclusively for GUI. Such gaming procs are far, far from being useful here.


Blt scaling should be directly and easily done via DDraw, since the GPU will do it 50-100 times faster and better.

FSAA is not for any current CPU. Do the math with the simplest, FSAAx2:
(30fps) * (2 windows) * (1024x768) * (FSAA 2x2+1+1) * (4 bpp) = 1080MB/s
Ah, where did I forget that we actually draw stuff before antialiasing it? So, add
(30fps) * (2 windows) * (1024x768) * (FSAA 2x2) * (Average overdraw=2) * (4 bpp) = 1440MB/s
Total 2520MB/s (oh, that's even more than what AGP 8x can provide)

Oh, that's just for two DrawRect(0,0,1024,768) - we didn't add read-bandwidth from surfaces! So, we add..., then alpha-blended, then...

You get the idea :)

SAIx2 is kind of the opposite of FSAAx2. Instead of which, one should better use the DDraw stretch. Unless it's used for the final stretch of an emulator of old consoles that draw sprites via palettes.
Posted on 2006-07-16 04:27:51 by Ultrano
Made the .lib again stand-alone, with all bug-fixes and additional features I've done for the past months.

New:
- Easy drawing to internal sSprites (bitmaps), instead of just to the back-buffer.
- More exported variables, for advanced use
- Loading of .jpg files and data
- More flexible initial-clipping via sdStartEx, and sdEndEx
- Interworking with GDI (use any GDI drawing func over the backbuffer)
- Fetching of background-data for transparency-effects when interworking with GDI
- Fast H-line and V-line procs
- some optimizations
- a new example: how to make a custom-control, drawn with sDraw
Attachments:
Posted on 2007-01-13 10:44:05 by Ultrano
P.S: whoops, had compiled the .lib with wrong params...

Posted on 2007-01-13 20:34:18 by Ultrano
Great :) I look forward to trying it
Posted on 2007-01-14 01:50:11 by mango