i'm thinking about coding public 2d graphic library. It should be coded in FASM (of course).

Any graphic library i know is not good for 2d graphic, directdraw's rendering is SLOOOW, 3d libraries are not reasonable for 2d game. What do you think about it?

And i'd also use few advices about multi-OS coding, i dont any experience with this.

Do you think it 'll be okay when access to video memory will be done through directdraw? (otherwise i'll need to code drivers for each card)

Here is the lastest version:

Do you really think that conding drivers for every card from scratch is a good option. So much work...
I think it would be better to code some library on top of DirectX, because IMO it's powerful, but not easy to use.

Take a look at Allegro ( www.alleg.sourceforge.net ). It is a great low-level library for games (for graphics too), but it's written in C. It shows how good library should be written, although IMO it contains some unnescesary stuff (like FLI animation). Anyway it's source should be very helpful when writing graphics library.

Btw, a few years ago I was writting a graphics library for Pascal. What I learned is that the planning is proably the most important part when writing such things

regards,
Decard

If you want it to run on different OSes mayby you should consider using OpenGL,

decard: yes, of course, planning is important in every bigger project. Taking experience in planning is one of my main goals. I want to make it so that i'll first design it's interface, how user sees it and then i can start writing code itself.
I'll surely look at allegro, but if it is pure C it won't be very fast and mine library won't be senseless. Maybe i could join theirs project with few fast assembly routines if i'll like their interface.

aaro: yes, of course i'll take look at it, now i am not experienced with opengl. In fact, everything i really need is setting video mode, access to video memory, and checking vertical retrace status, and maybe hardware blitting. Rest is not such important.

Hehe I forgot to said thet the most critical parts of Allegro are written in assembly Also I mention about that lib because it has some very good ideas, like BITMAP structure that is used for both accesing screen and memory bitmaps (you draw on them in the same way).

regards

Hi, vid. Just for sure.
Did you check this site?

http://www.melog.ch/mos_pub/

--

decard: geee, i'll have to check it's speed
fams9: now i did, but i didnt get the point. If you meant list of 3D libraries, i dont have time to check them all, but, they are 3D (!!!) libraries, so library optimized for 2D should be (much) faster. I'll just have to take a deep look at that Allegro.

sorry can't help.

check again, most of them written in FASM
http://www.menuetos.org/appl/appl.htm

--

decard: can allegro be compiled to DLL or it can be only staticaly linked? if can be DLL please send me working DLL (vid@InMail.sk), i dont have time and/or compilers to compile it. thanks.

By the way: Do you think such project could be useful?

Yes, allegro can be used both as an static library and DLL. I've just sent you an email with working DLL. If you need anything else form that package (like compiled examples) feel free to ask.


Of course! Sometime ago a very nice game was posted in this forum, and such projects could really benefit if there would be some good graphics library for Fasm, and it could be another reason for choosing this compiler

Perhaps you could also play a bit with the routines from my "kelvar", which you can download from the "examples" section of flatassembler.net? It works quite good even on 386 (as it was first programmed on such machine).

i've already seen it, but i didnt study graphic procedures. I liked it way to run 32bit code under DOS, great one (i'm not sure whether fasm for dos doesnt use it too - it should).

Anyway, i'm starting this project today. I have got a lot planning to do, i 'll post my ideas here so i hope there 'll be someone to discuss them. ok, thanks alot.

okay, here is documentation how TG2D (that's library name - TAJGA 2D graphic library) version 1.0 should look.
Take a look at it and comment it please.
Especially, i will like someone to find better names for part that i name 'procedure body', 'OS access' and 'routine' (this one is quite ok compared to those two).

By the way if someone want to join, be sure to post me.

I looked at your description - generally it's OK, but I have some notes about it. You may not agree to all of them, but you should consider them.

1. interface, procedure body, routines, OS access:
I recommend to use stack instead of registers to pass arguments - it's easier and more flexible solution, IMO passing agrs in registers is confusing, and isn't always faster.
Also, having two different interfaces (STDCALL in DLL and arguments via regs in COFF) is BAD idea. Interface should be common, it will be simpler and easier to learn.
2. Bitmaps:
Maybe you could start with 8bpp - it seems to be easier. Although you want to support only one bpp in 0.1, you should add "bpp" field into bitmap structure.
Have you looked at Allegro's bitmaps? IMO they are a bit too complicated, but they come with one excellent idea: they store pointers to each scanline. It makes drawing much faster, because you don't have to do "expansive" y*width multiply when calculating offset of a given pixel. The bad side is that the bitmap structure takes more memory, and have to be allocated dynamically (no static bitmaps) but I think this solution is better. As a consequence, SetMode won't take its bitmap parameter, it will create it itself and return pointer (and NULL in case of failture).
3. Names of routines:
- "GetVerticalRetrace" is definately too long name for this function, it could be for example just "Retrace".
- "Draw" isn't good too - try "Copy" or "Blit"
- maybe "SetGfxMode" instead of "SetMode"?
4. Other notes:
- I think you should use "td." preffix instead of "TD2D.". It's just easier to write something in lower case and without numbers

Also, small sugestion about hardware-dependent routines: your initialization routines should check whether MMX, SSE (etc) are avaible, and the setup some pointers, so you won't need to test CPU_FLAGS everytime, just do something like this:
(initialization part)

(routine)


It'll be faster

Hope this suggestions will be useful to you.
I wish I could help you in this project, but I'm already involved in Fresh, and I still need to spend much time in school But, maybe I could code something for you from time to time, and I will be giving you my suggestions if you will need them.

regards,
decard

1. hmm, on older processors using registers is always faster than memory (and this library is to be fast on older processors). But calling routine i not made so often to cause some slowdowns so i can take this.

BTW: but arguments to proc bodies should be passed in registers, because interface must be able to translate any argument passing standard, and translating to passing by registers is simplest.

interfaces - purpose of interface is to allow anyone define his own interface, it allows him to access library in the way he likes. If someone wants to use my library in OOP project, he just writes new interface.

2. with 8 bpp i would have to care about palette to make version 0.1 useful.

supporting bpp in bitmaps. I dont know about case when user wants bitmaps with anopther bpp than bpp of current video mode is. For this all bitmaps will be crated with current bpp. When bpp is about to be changed, bitmaps should be freed, and after mode is changed realocated. In future i will add procedure then will rerender bitmaps to another bpp.

Having array of pointers to scanline wouldnt be very fastening my library (in near future). Basic drawing procedures will just go through image (advancing to next pixel will be done with "inc esi" for example), whole drawing will be done in one loop without calling any other procedure, so i wont have to calculate position for every pixel. This will be needed later, when i'll code things like shading, blurring etc., which need to access pixel more than once, but it is far future and i will implement it then. I'm trying to keep it simple.

3. Retrace - good idea
Draw - i think Draw would be clearer for somebody who dont have experience with 2d interfaces. I didnt know what is 'blitting' when i was learning directdraw, it was only confusing me.
SetMode - in fact this would be TG2D.SetMode, so it is meant to set mode of TG2D. But, maybe in future there will be more kinds of modes of TG2D. What about SetVideoMode? This proc wont be called so often so name can be long.

4. Name is TG2D, not TD2D. i used upcase because TAJGA (something like name of team) is writen upcase. But you are partialy right, 'tg2d' would work better. 'tg' is too general, what will i use in other TAJGA library? Anyway, names can be changed in interface, i am trying to make such prefix that names will never confilct with any other defined in source, so nobody will have to rewrite library, only interface. Maybe you didnt comprehend usage of interface right because i skipped it in plans for 0.1

pocedure pointers - yes, i will do it this way. I just wrote that if routines for MMX and for SSE are almost same then you can write only one routine which will test cpu flags, and then set MMX and SSE routine names as aliases to this routine. This was explained poorly in docs.

Your suggestions were useful. In future i could use some help with Linux, and with usage of hardware acceleration under windows (directdraw or another way). I tried hardware accelerated blitting thru directdraw and it was slower than mine SMC routine. And i dont have access to computers whose video cards support things like rotation or scaling, so i cant compare these (ddraw's emulation is SLOOOW, it is writen in C++ or what).

1. I didn't mean that stack instructions are faster than registers> I meant that passing parameters via registers in many cases makes you to add some addictional code. Here's an example: say you're going to code simple putpixel routine. It will teke four arguments: some reference to the terget bitmap, x-position, y-position, and colour. So you will need to use all general purouse registers: eax, ebx, ecx and edx. And to pu this pixel you will have to make y*width calculation, so you will need another reg to store [width] variable. And proably you will need to preserve edx, because it's value is destroyed in MUL instruction. Of course that preservations could be avoided somehow in this case, but it shows you the problem.
2. Do you really think that palette is a real problem? In first release you could even not care about it. But it's your choice, and it is not important, as you proably are going to code all bpps in future
About "BPP" fileld in bitmap structure: I still think it should be there, for example when user will be coding something like color-conversion routine.
Scanline pointers: I agree that at least now you should keep the whole thing simple. But think about lines or circles. Proably they will be drawn using putpixel as a base, and it will have to MUL on each pixel... So I think that it would be good to add pointers in future.
3. I still don't like "Draw". You can draw pixel, draw line, etc. So maybe "Copy" or something like this?
And IMO SetVideoMode is OK.
4. sorry, my mistake. I meant 'tg.', not 'td.'. And I agree with you
now, in this case 'tg2d.' should be ok

Well, I also have many trouble when I try to explain something in english, so don't worry about it But I realized that when I'm posting and reading posts, I'm also learning english

1. i finally decided to pass through stack. It is most of time chached and routines are not called often so it is ok.

2. Palette IS problem. I want to start my library with some mode with paletized colors, not indexed (color number itslef contains RGB values = paletized, indexed = you must look up RGB in table).

I decided that BPP will be there, but it will be problem if you want draw bitmap onto another with different bpp. It will make routines MUCH harder to code and maybe slower. What about not allowing drawing bitmaps onto other with different bpp? Library would only have some conversion function, and you will have to convert bitmap to draw. Again, maybe later....

In drawing line you dont need multiply for each pixel, you can precompute differences. This is worser for circle, but i havent thinked them yet, i'll see later

btw: i have problems too of course, and up to now i understood everything you wrote. i also realized, that under windoze applicatin window is handled by tg2d, o there should be some task-switching callback. Another possible way is by letting user take over window procedure, but i think callback is enough, what else should he want to do with window? (i am talking about fullscreen modes now)

Now I fully agree to your approach
Unforunatelly I can't help much with windows, I have no experience in multi-threading programing.
Good luck!

PROBLEM1:
is number of bits per pixel needed? Wouldnt byte per pixel be better? No card i know support modes with bits per pixel not divisible by 8 (except 1, 2 and 4 which wont be supported anyway).
This is kind a unusual but effective, no?


PROBLEM2:
under windoze with using ddraw i cant simply provide bitmap for video
framebuffer. To gain access to this memory i must lock it in directdraw, and
while it is locked ddraw has some "win16mutex" what means it is only process that runs at this time. So buffer can't stay locked, and when it is not
locked then pointer to pixel array is not valid.

i have several solutions:

1.provide bitmap, but with .bmp member = 0 while surface is unlocked. When it is locked, .bmp will be set, and zeroed after its unlocked. If some operation of tg2d is done on this bitmap when unlocked it will be automaticaly locked and unlocked. Code will look same, except for case when .bmp member is 0.
However, the procedure body would have to contain code that will be obscure for some platforms.

primary = tg2d.SetVideoMode()
Draw(primary, ...) //here Draw() will lock and unlock buffer

Some explicit Lock and Unlock could be defined too.

Lock(primary)
//hand draw into primary->bpp pixel array
Unlock(primary)

and for cases of multiple drawings too:

Lock(primary)
for (x=0; x<N; x++)
Draw(primary, image[x], ...)
Unlock(primary)


2.provide just some procedure (Show) to draw bitmap onto video ramebuffer bitmap. Maybe i could implement backbuffer by default, by i dont like this until it is needed. This way will be unique for all platforms, but will make library usage slightly more complicated and user will never have direct access to video memory.

tg2d.SetVideoMode(...)
back = tg2d.CreateBitmap(...)
Draw(back, ...)
Show(back)

3. similar to 1: Init and SetVideoMode will return bitmap only under OSes where locking is not needed, on others you have to call Lock to get bitmap

primary=tg2d.SetVideoMode(...);
MustBeLocked = (primary == 0);
if (MustBeLocked) primary = Lock();
Draw(primary, ...);
if (MustBeLocked) Unlock();

i dont like any of these methods. If you have any idea you could advice...

Method 1 looks best, but as i told, procedure body will contain some code which will be obscure under some platforms.

(best solution would be some other way than ddraw to access video framebuffer directly...)

ad 1:
Why do you want to use bytes per pixel? Bits per pixel is a standard, breakin it might be confusing. Also, I read that some older cards don't support 16bpp, but only 15. What about them? I don't think that bytes per pixel would be good.

ad 2: solution 1 is the best in this case. On other platforms Lock and Unlock would just do nothing. Having a separate func that will draw on screen only will limit your library.