flat assembler
Message board for the users of flat assembler.

Index > Main > 2d graphic library project

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 09 Feb 2004, 05:47
then it crashes in SetCooperativeLevel, not in SetDisplayMode. I bet it is something with application window. OK, just some more work
Post 09 Feb 2004, 05:47
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
S.T.A.S.



Joined: 09 Jan 2004
Posts: 173
Location: Ru#27
S.T.A.S. 10 Feb 2004, 07:24
Hi, vid
I have a very small suggestion for your library.

Try to avoid using DX Lock method frequently, it's very slow to use it for each output.
When I'm in fullscreen, I do something like:

- Lock
- draw *everything* to backbufer (it should be located in system memory, if hardware acceleration isn't used, VRAM is slow)
- Unlock
- Wait_for_vertical_blank (VSync)
- copy backbuffer to primary surface by hardware (or better copy to videoram backbuffer, then Flip)
- do other job
- loop


Also, I've got a small include file to help parsing DX errors at runtime (if they are).
If make simple modification of macro that calls DX COM methods and add one text file to exe's directory (I have one with some error descriptions of DX7, but it can be easily extended) it could show a MsgBox with error description.
If you like, I'll send it to you via email (I heven't converted it from masm yet, but should be no problems with that)


Regards
Post 10 Feb 2004, 07:24
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 10 Feb 2004, 07:33
1. of course, i know this Lock() stuff. But currently TG2D doesn't support backbuffer in video RAM.

2. On other side, you should stay Lock()ed as short as possible because windows locks process (even if you give him flag not to lock process) and so it breaks multitasking.

okay send it (I have seen suc h example in DX SDK examples - DDErrLookUp)
Post 10 Feb 2004, 07:33
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
S.T.A.S.



Joined: 09 Jan 2004
Posts: 173
Location: Ru#27
S.T.A.S. 10 Feb 2004, 10:05
I did some tests, with videoram speed.. Though we can write to it w/o penalty (as we could hope), but to read from it is difenitelly slow. So what about software alpha-blending, etc? When we use main memory, we can do some tricks with cache, and it could give us 2x speedup and even more.
VRAM is IMHO only for hardware blitting (VRAM -> VRAM) when we speak about 2D.

About breaking multitasking.. Well, why we need some Exel calculating 2+Gb table when we play cool game Wink I don't know how deep Lock gous into kernel, but any way it may be really slower than draw a sprite.


and..
don't forget to check your inmail box
Post 10 Feb 2004, 10:05
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 10 Feb 2004, 13:36
due to my info writing to vram via CPU is about 2x slower, reading about 5x slower. (but there are no penalties if you turn off display with some VGA registers Smile

you are right about vram reading, that's why i didnt explicitly provide backbuffer with TG2D. I must think about some nice solution.

in DX SDK is writen that it takes Win16Mutex, sometimes called Win16Lock. There is a flag which tells him no to take it but it is almost 100% undocemented and doesnt work when you lock primary surface.

i have experiences, when i was coding similar game along with friend. i was doing ram -> vram blits with my own optimized proc, he was using vram -> vram via ddraw and my game was about 2fps faster.

btw, what do you thing about triple buffering, is it something to take in mind when designing TG2D?
Post 10 Feb 2004, 13:36
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 10 Feb 2004, 19:23
hi, new try.

just aligned window procedure.
Post 10 Feb 2004, 19:23
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Blag



Joined: 04 Jul 2003
Posts: 90
Location: Perú
Blag 11 Feb 2004, 03:35
Excelent example Vid! Wink

Really cool....but.....can you make the like rectangle, bounce around the windows????? Razz

_________________
Alvaro Tejada Galindo
SinglePath games design
http://www.iespana.es/singlepath
Post 11 Feb 2004, 03:35
View user's profile Send private message MSN Messenger Reply with quote
S.T.A.S.



Joined: 09 Jan 2004
Posts: 173
Location: Ru#27
S.T.A.S. 11 Feb 2004, 03:37
IMHO, 2x & 5x numbers will depend on hardware.
Of cource if we're useng small sprites, hardware will sux, It's good only to move *big* sprites.
This is because access to hardware through a driver takes *some* time to go to ring 0 etc..
That's why I think backbuffer is *must have* - we can Lock it and draw anything we want by CPU
Smile

I know about Win16Mutex.
Also I heard there are some comercial games, that Lock mem for all the time they are rumming and unlock it when they are minimized or closed.
IMHO this related to 16bit GUI code of win9x and don't affekt 32 bit system core. Especially on NT systems.
I used to Lock it at least for 80% of CPU time - no problems.

I think triple buffering could be a cool solution to solve all problems. Everithing should be drawn on "memory backbuffer" and then moving by hardware to VRAM. I've written so ^^ .
Still I'm not sure that there will be any noticeable speed difference between such scheme and using only 2 buffers (one - in primary surface, and another in system RAM).
Also in windowed mode we just can't use Flip method

PS
I have no problems running your procs on my radeon 8500 video.
Post 11 Feb 2004, 03:37
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 11 Feb 2004, 13:34
so how do you suggest TG2D should handle backbuffer(s)?

Let user choose no back / one backbuff with flip / triple buffering?
Post 11 Feb 2004, 13:34
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
S.T.A.S.



Joined: 09 Jan 2004
Posts: 173
Location: Ru#27
S.T.A.S. 11 Feb 2004, 23:25
May be tg2d.SetVideoMode should use one more parameter (number of buffers) and automatically create all surfaces at DX setup..
Then all other parts could be unchanged (because anyway just one surfase will be used for drawing).
But in this case some tg2d.Visualize method would be needed.
When no backbuffer(s) are used it will do nothing, otherwise it must do some blitting and Flip.
Also, in fullscreen Visualize could synchronize with VSync signal.

BTW, what do you think about errors handler, is it really silly?
Post 11 Feb 2004, 23:25
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 12 Feb 2004, 14:15
i thinke about this too, but at most 3 backbuffs may be needed. Otherwise it is just as i meant, except for tg2d.Visualize, i will rather use tg2d.Show (it is shorter and it is much clearer for newbie what it does)

ehm, i didnt comprehend your question. what error handler did you mean, TG2D's? And why silly?
Post 12 Feb 2004, 14:15
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
S.T.A.S.



Joined: 09 Jan 2004
Posts: 173
Location: Ru#27
S.T.A.S. 12 Feb 2004, 23:47
Yeah, about name "Show" it'd be better

vid wrote:
. what error handler did you mean, TG2D's? And why illy?

No, one I have sent you Smile
(maybe my 2nd letter lost somewhere)
Post 12 Feb 2004, 23:47
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 13 Feb 2004, 08:18
aaaaah, THAT error handler, i was brain dead. Embarassed

it is alright, but i'll rather use DXGetError, when i find in which DLL is it declared. (it is quite succesfully hidden somewhere)
Post 13 Feb 2004, 08:18
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
S.T.A.S.



Joined: 09 Jan 2004
Posts: 173
Location: Ru#27
S.T.A.S. 13 Feb 2004, 15:08
Hmm.. Are you sure about GetError name? Is it COM-interface method or "normally" exported? I did a few attempts to find it (without results), may be it's used only in debug versions of dlls.. I hope I'll go deeper in that a bit later. It's kinda interesting Wink
Post 13 Feb 2004, 15:08
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 14 Feb 2004, 17:39
names are DXGetErrorStringA (or W) and DXGetErrorDescriptionA (or W). In C headers they are globally declared, not COM methods. But i couldn't find them in export of any DLL in system32.
Post 14 Feb 2004, 17:39
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
triglav



Joined: 20 Feb 2004
Posts: 6
Location: Slovakia
triglav 20 Feb 2004, 18:17
Hi, I'm the Vid's coding-companion in our 'TAJGA Team'. I'm mainly (sorry) a C++ programmer (of course there are more languages, which with I'm a friend) and a big GNU/Linux fan. With FASM (and ASM) I have no true experience (I was using only MASM for couple of weeks) even though I think that this project (FASM) is really great. I joined to this forum because I think (hope) that my coding experience with some, here noted things, could be at least a bit valuable. So pls don't stone me, if I say sometime something, you won't agree with.

My first note is, that the functions like DXGetErrorString() were implemented firstly in M$ DX 8.1 (I'm not really sure if they were already in DX 8.0, because I've never used this version). Concrete in the DxErr8.lib (libDxErr8.a), and it's size is 1MB!
I think, that 'tg2d' should be in the future coded also for Linux, and for that reason it'll be clever to use DX only for an access to the video memory. And for this purpose, it's sufficient to use DX 1 (or 3). so for catching errors you should go some other way.
Those mentioned functions are only some form of wrappers for converting DXs HRESULT to string message, plus they also call an API function GetLastError(). It's not hard to write own wrapper for converting DirectDraw HRESULT to string message. It'll be also more compatible with ancient machines without software update.
For example, here is a part of (C++) code from my last DX project. Of course it could be solved smarter if you change a switch() statement to some sort of associative array, or something like that.

What about 'OS access' wrapper connected to SDL? It's today widely used library for open-source projects. It would be also easier way to port tg2d to Linux.

I'm looking forward your first linux release!

PS: pls, reduce documentation textwidth to 78 characters. reading it in Linux text console is really awful.


Description:
Download
Filename: DD-Results.ZIP
Filesize: 3.23 KB
Downloaded: 439 Time(s)

Post 20 Feb 2004, 18:17
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 21 Feb 2004, 11:37
heh, hi, glad you registered.

1. It doesn't matter which .lib is it in, .lib can import from any DLL.

2. about using only v1 is right. I have probably forgotten about multiplatforming tg2d here, i'll resolve messages myself.

3. Hmm, SDL is just set of wrappers for some OSes, and i don't want my library to be wrap of wrap of wrap (like tg2d - SDL - ddraw). Also this way, it will have more power when using OS's interface (ddraw) directly. tg2d os access will not be ONLY getting access to video memory, there is also some hw-blitting and backbuffering required. And hw-scrolling etc. later. In one more indirection via SDL will be only slowdown. But anyway, i can write SDL os-access module, so tg2d would be ususable under all platforms that support SDL.

4. ok, look forward, but i will have to learn something about linux coding first Smile

5. yes, i think so. I was using 100 for my personal usage as it is easier to read in 1024 resolution under wdoze. But why 78, why not 80?
Post 21 Feb 2004, 11:37
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 21 Feb 2004, 19:10
new testing version there, check it pls

-- -------------------
Here is idea how tg2d backbuffering support could look:

in call to AccessOriginal (obtaining access to screen without modifying it) or to SetVideoMode (changing resolution & access
to screen) you will pass one more argument in EAX, flags. 2 flags will be reserved for backbuffering, with values.

00 = no tg2d backbuffer, user can maintain RAM backbuffer himslef or dont use any backbuffer. tg2d.Show returns error.

01 = one video memory backbuffer, flipped by tg2d.Show, if not enough vram 11 is used

10 = two video memory backbuffers, flipped by tg2d.Show, if not enough vram 10 is used, if still not enough 11 used

11 = ram backbuffer, blitted by tg2d.Show, if not enough ram error returned.


Description:
Download
Filename: tg2d v0.0.3.6.zip
Filesize: 22.46 KB
Downloaded: 476 Time(s)

Post 21 Feb 2004, 19:10
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
triglav



Joined: 20 Feb 2004
Posts: 6
Location: Slovakia
triglav 22 Feb 2004, 19:46
vid wrote:
But anyway, i can write SDL os-access module, so tg2d would be ususable under all platforms that support SDL.

partly right -> under platforms that supports SDL & FASM Idea that was the main idea of SDL os-access module.

now, I think that os-access should be renamed to some other name, because the access to os has been changed to the access to os through other technology/library (DX, OpenGL, Xlib, SVGALib, GGI, etc.), what about gfx-cotroller or gfx-access?


vid wrote:

ok, look forward, but i will have to learn something about linux coding first Smile

you probably need someone to porting to Linux. in my opinion when you try Linux, you'll need someone to porting to Lose-dows Cool


vid wrote:

yes, i think so. I was using 100 for my personal usage as it is easier to read in 1024 resolution under wdoze. But why 78, why not 80?

simply because Linux text console is 78 characters wide (I think that DOS "text console" is 80).


writing documentation during development is great thing and a good habit, but writing it in a pure txt form is today for some folks insufficient. it's good, if you are able to nicely print out whole documentation on a paper, or convert it for example to html. also maintaining it by number of people is hard. so I recommend to use for documenting DocBook. This utility is for example used in projects like PHP, KDE, etc.


PS: under "Win98 SE" runs "tg2d v0.0.3.6" fine Wink
Post 22 Feb 2004, 19:46
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard 23 Feb 2004, 07:57
Him vid!

Finally I was able to successfully run test.exe on my machine Wink Only thing is that I got rid of WinME, I'm using 98SE now. Anyway great work Very Happy

regards
Post 23 Feb 2004, 07:57
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.