Hello everyone,
Here are some examples that I made with my assembly library TurboAsmDX, and would like to know how they work on your system, If you could could you give a brief description of the type of computer you are using and the os/directx version?
thanks,
MadMatt

P.S. Oh yeh, the system requirements are: pentium with mmx, windows 98 or better, and directx 7 or greater.

XP SP1 DX8.1 XP2500+ MMX 3DNOW
Check OK

works fine on winXP SP2 directX 9.0c Athlon XP 64 3000+ radeon 9550. Nice examples

All right, thanks guys. Anybody else?

Ddplasma32.exe, Colorful.exe - do not work at all
Ddplasma8.exe, PixelDesigns.exe, RotoZoomerGfxBuffer.exe - work ok
Mystify.exe - works, but not smooth

cel1100/128/i815(built-in video)/dx8.1/w2k/800x600x24

i'm not familiar with garfic - maybe some system settings can cause such working (?)

all of our examples worked fine on my computer:
* W2K SP4
* 1280x1024x32 85Hz
* DX 9.0c
* AMD Athlon 1,4 Ghz
* 1Go RAM
* NVIDIA GeForce4 FX 5500

but, like shoorick, "mystify" wasn't really smooth

and i wasn't able to compile cause i missed TurboAsmDx.inc into your zip package

shoorick - do you have the latest drivers for your video card? the two examples that you mention require 32-bit color, Your video card may not support them, I use a 32-bit color depth, I'll upload some using 24-bit, see if this helps.

1. Yeh, this is a very bad (slow) mystify clone, will try to make a faster one

2. You cannot compile these examples with the FASMW standard include package, these functions require my include files, which have many more equate/api definitions and my personal macro collection.

3. If anyone cares, I could upload my include folder, you would have to use the latest FASMW release (1.64 - Nov 9 or greater), and would have to remove (cut & paste) your old include folder and replace it with mine, then you could compile the examples. When I finish the next round of examples, I'll include a quick reference of all the functions in the library.

OS: w2k3 sp1
cpu: cel 1.8
dx: 9.0c
video: nvidia fx5700
ram: 512mb

all works OK, "mistify" not so smooth

madmatt: finding bugs in ddraw code is extremely hard, and i know what i m talking about (instandard handle to background brush of ddraw window class can cause SetCooperativeMode crash (GPF), even though ddraw window is never redrawn using that brush. And GPF crash means either complete freeze of computer or just terminating application without any message). Best i can advice you is precise logging in some debugging version.

vid: so are you saying you are having problems with these examples? I haven't had any more problems than anything else i've done over my many years of programming, It's tough if you new to assembly, don't know how to use assembly debuggers, and used to high level hand holding. There's a few times that I had to dig deep to find the problem, but this happens in any medium to large project.

flaith: I'm uploading 2 examples that specify a 24-bit screen, hopefully, the driver says it want's 24-bit but really is 32-bit, just name 24-bit for lack of alpha channel.

everyone: I will also upload my includes which have major additions to the standard fasmw windows includes.

See above for latest update
enjoy!
MadMatt

no, not with these examples, i didn't try them... (sorry, no time). i was talking about winapi<-->ddraw problems generally. I believe that if you stick to ddraw you will soon find out what i am talking about..

hi, madmatt!
testing of colourfull24: i see only b/w vertical lines thin enough
plasma24: works, but b/w and also has vertical lines.

i got this pc at work a few days ago, did not mess in all drivers yet, but not sure there is a problem with them

regards!

Ddplasma24.exe & Colorful24.exe crash instantly, others work, but like others have stated mystify is slow.
-Intel Celeron 330
-MMX,SSE,SSE2,SSE3
-Intel D845GVSR (82845G integrated video w/ ~13MB RAM)
-DX 9.0c
-Windows 98 SE

Thanks MadMatt

shoorick: My examples are using 32-bit color, 4 bytes per pixel, your video must be using 3 bytes per pixel. I'd write functions for them, but infortunately, my video card does not support this mode, so i would not be able to test them.

flaith: your welcome!

vid: I haven't found any problems I couldn't fix yet, but I still have to add overlay support, so maybe I'll change my mind . Much software still uses directdraw, even in the gdi-plus includes I see a directdraw surface defined. I have the beginnings of a direct3d 2d interface in my dll library, but no examples showing this yet . I still like directdraw because it's just much easier to do a blit than with direct3d (in my opinion).

i used it only until i was able to draw into backbuffer with my own routines (eg. initialize, flip backbuffer, uninitialize). Drawing with my own routines was faster than with ddraw's blit :] (which should be done by video card not processor btw.) And i didn't have to store bitmaps in one image file with lot of space wasted because of placement of pictures

madmatt > i understand it is 24/32 problem. i can not help you fast because i'm currently buzy at work and had never been practiced with graphics on ibm, but always can test any your post. you can even send me tests by email . at home i have nVidia, so, also can not test 24-bit grafics, thus only at work.
btw, i found your includes very usefull. keep on your good work! regards!

vid: How could your software blitters be faster than directdraw's hardware ones?!?!? hardware blitters go at least 20-50 times faster than the best assembly software blitters. You must have a shitty video card then.

shoorick: I may make 15/16 bit color versions so everyone can try them even on old hardware, thats the best solution I can come up with right now

madmatt: theory... yes, i do have shitty video card (notebook), but i was testing it on non-shitty video card too. Problem is (i think) that all the overhead ddraw produces until it really sets up hardware blitting takes more than blitting it by processor. It can be efficient when blitting pictures about 200x200 or so, but not on 32x32, or even maybe 64x64.

Just read about ddraw's layers, you will see what it has to go through until it can blit. And count stupid M$ bloaty coding and you see it cannot take less than 16x64 movsds + few instructions more. And i even wasn't using MMX. And, i believe, in some cases (unsupported clipping etc.) ddraw uses it's own routines which must be really slow (at least compared to brute-force optimized asm blit )

works @:

windows xp home sp2
p4 2.83 ghz
dx 9.0c
GeForce4 ti 4800 SE