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 |
|
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
|
|||
09 Feb 2004, 05:47 |
|
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) |
|||
10 Feb 2004, 07:33 |
|
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 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 |
|||
10 Feb 2004, 10:05 |
|
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
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? |
|||
10 Feb 2004, 13:36 |
|
vid 10 Feb 2004, 19:23
hi, new try.
just aligned window procedure. |
|||
10 Feb 2004, 19:23 |
|
Blag 11 Feb 2004, 03:35
Excelent example Vid!
Really cool....but.....can you make the like rectangle, bounce around the windows????? |
|||
11 Feb 2004, 03:35 |
|
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 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. |
|||
11 Feb 2004, 03:37 |
|
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? |
|||
11 Feb 2004, 13:34 |
|
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? |
|||
11 Feb 2004, 23:25 |
|
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? |
|||
12 Feb 2004, 14:15 |
|
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 (maybe my 2nd letter lost somewhere) |
|||
12 Feb 2004, 23:47 |
|
vid 13 Feb 2004, 08:18
aaaaah, THAT error handler, i was brain dead.
it is alright, but i'll rather use DXGetError, when i find in which DLL is it declared. (it is quite succesfully hidden somewhere) |
|||
13 Feb 2004, 08:18 |
|
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
|
|||
13 Feb 2004, 15:08 |
|
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.
|
|||
14 Feb 2004, 17:39 |
|
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.
|
|||||||||||
20 Feb 2004, 18:17 |
|
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 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? |
|||
21 Feb 2004, 11:37 |
|
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.
|
|||||||||||
21 Feb 2004, 19:10 |
|
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 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:
you probably need someone to porting to Linux. in my opinion when you try Linux, you'll need someone to porting to Lose-dows vid wrote:
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 |
|||
22 Feb 2004, 19:46 |
|
decard 23 Feb 2004, 07:57
Him vid!
Finally I was able to successfully run test.exe on my machine Only thing is that I got rid of WinME, I'm using 98SE now. Anyway great work regards |
|||
23 Feb 2004, 07:57 |
|
Goto page Previous 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.