flat assembler
Message board for the users of flat assembler.
![]() Goto page 1, 2 Next |
Author |
|
BXM 21 Nov 2005, 12:09
XP SP1 DX8.1 XP2500+ MMX 3DNOW
Check OK |
|||
![]() |
|
decard 21 Nov 2005, 12:22
works fine on winXP SP2 directX 9.0c Athlon XP 64 3000+ radeon 9550. Nice examples
![]() |
|||
![]() |
|
madmatt 21 Nov 2005, 13:13
All right, thanks guys. Anybody else?
|
|||
![]() |
|
shoorick 21 Nov 2005, 14:31
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 (?) |
|||
![]() |
|
flaith 21 Nov 2005, 14:40
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 ![]() _________________ Je suis sur de 'rien', mais je ne suis pas sur du 'tout'. |
|||
![]() |
|
madmatt 21 Nov 2005, 15:17
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. |
|||
![]() |
|
Ivan2k2 21 Nov 2005, 19:24
OS: w2k3 sp1
cpu: cel 1.8 dx: 9.0c video: nvidia fx5700 ram: 512mb all works OK, "mistify" not so smooth |
|||
![]() |
|
vid 21 Nov 2005, 20:28
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.
|
|||
![]() |
|
madmatt 22 Nov 2005, 02:06
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 |
|||
![]() |
|
vid 22 Nov 2005, 05:28
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..
|
|||
![]() |
|
shoorick 22 Nov 2005, 07:07
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! |
|||
![]() |
|
Madis731 22 Nov 2005, 09:01
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 |
|||
![]() |
|
flaith 22 Nov 2005, 10:05
Thanks MadMatt
![]() _________________ Je suis sur de 'rien', mais je ne suis pas sur du 'tout'. |
|||
![]() |
|
madmatt 22 Nov 2005, 11:36
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 ![]() ![]() |
|||
![]() |
|
vid 22 Nov 2005, 12:42
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
|
|||
![]() |
|
shoorick 22 Nov 2005, 15:45
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
![]() btw, i found your includes very usefull. keep on your good work! regards! |
|||
![]() |
|
madmatt 22 Nov 2005, 23:37
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 |
|||
![]() |
|
vid 22 Nov 2005, 23:54
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 ![]() |
|||
![]() |
|
RedGhost 23 Nov 2005, 09:13
works @:
windows xp home sp2 p4 2.83 ghz dx 9.0c GeForce4 ti 4800 SE _________________ redghost.ca |
|||
![]() |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.