Life After DirectDraw...

Life After DirectDraw...

Edward Sheets

Member #4,734

June 2004

When Direct3D completely drops support of the deprecated DirectDraw API, will all of our Allegro apps which use GFX_AUTODETECT default to using the GDI driver?

Has anyone seen a timeline showing when DirectDraw will be completely banished from DirectX? I've just seen warnings on MSDN that support "may be dropped at any time".

---

Note: carving a pentagram on the top of a container of spoiled yogurt does not summon a yogurt demon. -Kikaru

Kitty Cat

Member #2,815

October 2002

I believe that only applies to the SDK. I highly doubt DirectX drivers will drop the driect draw functions.. too many games rely on them. And if the SDK does drop them (which would be a stupid move at this point in time, IMO) we still have the older SDKs available.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

miran

Member #2,407

June 2002

When that happens Allegro will be even more a 1996 library than it is today. I can already see newbie threads:

Q: "I want to install Allegro but I'm having problems. Pleas help!"
A: "You have to get the DirectX SDK from 7 years ago. Allegro doesn't work with anything more recent!"

--
sig used to be here

Evert

Member #794

November 2000

Allegro works fine with DX9.

There is an experimental Direct3D driver floating around somewhere that someone could pick up and start working on again. I'll be damned if I know what I did with it though (I can probably dig it up in my mail if I have to).

For 4.3, it wouldn't be bad if someone took on the job of writing a proper new and updated Windows driver, as opposed to Elias, Peter, me and others trying to hack the existing code into something servicable.

Edward Sheets

Member #4,734

June 2004

Kitty Cat said:

I believe that only applies to the SDK. I highly doubt DirectX drivers will drop the driect draw functions

Good

I hope Microsoft has the good sense to always continue support for DirectDraw. The thought of having to learn Direct3D just to do basic 2D games is absurd.

[edit]
Are there any real advantages to moving to a D3D driver?

---

Note: carving a pentagram on the top of a container of spoiled yogurt does not summon a yogurt demon. -Kikaru

Kitty Cat

Member #2,815

October 2002

Quote:

Are there any real advantages to moving to a D3D driver?

Over the current one? More hardware acceleration. Over a proper DX7/DDraw one? Not much, probably.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

gillius

Member #119

April 2000

AFAIK everything that you could do with DirectDraw could be done with D3D, and better, except for maybe direct access to the screen buffer. This is where Allegro breaks down for most hardware APIs is because it allows you direct access to the screen. Really, Allegro's API is just too old to fit into modern realities of computer games. OpenLayer and/or AllegroGL are probably better choices now.

Gillius
Gillius's Programming -- https://gillius.org/

Edward Sheets

Member #4,734

June 2004

gillius said:

OpenLayer and/or AllegroGL are probably better choices now.

Would it be unthinkable (or impossible) to create a driver for Allegro that would use OpenGL hardware acceleration wherever possible instead of having to use addon libs for OpenGL?

---

Note: carving a pentagram on the top of a container of spoiled yogurt does not summon a yogurt demon. -Kikaru

Evert

Member #794

November 2000

Quote:

This is where Allegro breaks down for most hardware APIs is because it allows you direct access to the screen.

That is not nescessarily guarenteed in the new graphics driver API for 4.3.
It currently lives on the existing drivers (and still lacking some features and abilities) and so does actually do it right now, but it's free not to do that in the new design, unless the user requests it (in which case it would allocate an extra memory buffer for reading).
Of course, this is where it must go - not where it is right now. Right now, getting 4.2 has priority over 4.3. When 4.3 gets promoted to mainline, we will probably need more help getting things to work peroperly on all platforms.

As for using direct acces to the screen in Allegro - who actually does that? I certainly never have.

EDIT

Quote:

Would it be unthinkable (or impossible) to create a driver for Allegro that would use OpenGL hardware acceleration wherever possible instead of having to use addon libs for OpenGL?

That's part of what AllegroGL does. The vtables are incomplete though.

Fladimir da Gorf

Member #1,565

October 2001

Quote:

Would it be unthinkable (or impossible) to create a driver for Allegro that would use OpenGL hardware acceleration wherever possible instead of having to use addon libs for OpenGL?

Not impossible, but as we can see from AllegroGL
- it's a non-trivial job
- it'd work slower (sometimes a lot slower) than using a native api (OpenLayer)

OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori)

guilt

Member #2,553

July 2002

DD functions shall be used for as long as they can. Allegro hasn't used DD7 blitting functionalities till date (including HW support for blended sprites), and probably that's as far as it can get.

I've been hearing about D3D 10 (or whatever the next version is) allowing pixel access to the framebuffer, but it will probably be through Pixel shaders. Also, the 2D blitting performance using D3D will be comparitively _slower_ If, however, you are interested in porting the 3D functions away from the API, just add on a D3D driver...

Karthik Kumar Viswanathan

Website

Thomas Fjellstrom

Member #476

June 2000

Um, you can already get pixel access to the frame buffer in GL. I recall Bob saying its rather standard, at least on semi recent Nvidia cards. And its FAST. That is to say, on Nv chips you can easily hit the fill rate limit.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

guilt

Member #2,553

July 2002

Well, I suppose then it would make more sense to specify the range-of-hardware on which Allegro and it's drivers would be compatible

Karthik Kumar Viswanathan

Website

Raf256

Member #3,501

May 2003

Bah, the OpenGL (not to mention stinky directX) is way overrated.

Take into account that no every program consist only of blits or draw_sprites. Some programs are applications that need other approach (like normal lines, circles, etc). The reular blitting and normal drawing functions are realy fast.

It would be best to IMHO have option to allow GL accell for only blit-family things (expecialy when they include also scale, rotate, etc).

I would do it as:
draw_sprite() - will use normal driver, or it will use openGL if 1) OGL driver is loaded, 2) it is enabled for Blit-familly 3) target is the screen
scr_draw_sprite() - exacly as above, but sets the TARGET to screen BITMAP* (a bit faster calling of functions)
gl_draw_sprite() - always use OpenGL and always draw to screen (skip the first parameter)

similar: line() scr_line() gl_line()

Functions:
EnableGlBlits(1); // enable (or disable) calling gl_draw_sprite for draw_sprite(screen,...) and for scr_draw_sprite()
EnableGlOther(1); // same for other like line() vline rect
EnableGlPoly(1); // same for polygons especialy polygon-3d functions

IMHO it would be also interesting to provide new type of BITMAP* - the accumulator buffer

BITMAP *buf = create_accum_bitmap(256,256, 24, 8); // 256x256 24bpp + 8b alpha
accu_draw_sprite(buf, monster_blurred, 50,50);
accu_draw_sprite(buf, monster_blurred, 51,50);
accu_draw_sprite(buf, monster_blurred, 50,51);

Hmm about the prefixes accu_ scr_ gl_ ... first of all I suggest that they can be in mostly auto-generated (not to tripple developers work) from C preprocesor in macros. It could work a bit faster when no need to check to type of BITMAP* and to pass it if it is screen.
Perhaps:
(BITMAP bitmap, *); // - will call mem_ scr_ gl_ or accu_ depending on bitmap
mem_*(BITMAP* memory_bitmap, *); - draw to normal allegro memory bitmap
accu_*(BITMAP* memory_bitmap, *); - draw to openGL accumulatiung buffer
scr_*(BITMAP* memory_bitmap, *); - draw to screen, using OGL or not depending on currect enable OGL settings and type of function
gl_*(BITMAP* memory_bitmap, *); - draw to screen using openGL

Hmm perhaps I written it a bit chaotic but some parts of the idea abbove should be usefull IMHO.

Evert

Member #794

November 2000

Raf256 said:

draw_sprite() - will use normal driver, or it will use openGL if 1) OGL driver is loaded, 2) it is enabled for Blit-familly 3) target is the screen
scr_draw_sprite() - exacly as above, but sets the TARGET to screen BITMAP* (a bit faster calling of functions)
gl_draw_sprite() - always use OpenGL and always draw to screen (skip the first parameter)

Allegro uses vtables that hide the distinction from the user. It already (potentially) uses dedicated functions for mem->mem, mem->vram, vram->vram (and vram->mem) blits.
If the bitmap in question is a video bitmap, then the blit to screen would automatically use the (possibly/ideally hardware accelerated) vram->vram blitter. There's no need to add dedicated functions for doing that or add the complexity of what you're suggesting. It only makes the interface more chaotic than it needs to be.

guilt

Member #2,553

July 2002

Kind of like a poll: which one do more guys wanna work more on.. DDraw/GDI or OpenGL/GDI?

Karthik Kumar Viswanathan

Website

Raf256

Member #3,501

May 2003

Quote:

There's no need to add dedicated functions for doing that or add the complexity of what you're suggesting. It only makes the interface more chaotic than it needs to be.

Indeed.
And how about adding the accumulating buffer then?

About Direct/OGL, I would rather use OGL with is a serious software, not micro$oftich thingy. On the other hand OGL is often not so good implemented in windoze.
If there is a way to request refresh mode in OpenGL (with often defaults to 60 Hz due to poorly OGL drivers for win) with is a big problem, then I would rather go for OGL.

Kitty Cat

Member #2,815

October 2002

Quote:

On the other hand OGL is often not so good implemented in windoze.

I've never had a problem with OpenGL under Windows, as long as I have the latest drivers. The default/software implementation on any system is inadequate for real-time usage. The only thing about MS's is that it's buggy and crash-prone.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Raf256

Member #3,501

May 2003

Quote:

I installed newest nvidia drivers for my wintendo box and still I have in meany OGL games resolution of 60 Hz

guilt

Member #2,553

July 2002

Well, the DXSDK is more standardized wrt OpenGL SDKs

Well, we still gotta use DX for Input, anyway ...

Karthik Kumar Viswanathan

Website

Evert

Member #794

November 2000

guilt said:

Kind of like a poll: which one do more guys wanna work more on.. DDraw/GDI or OpenGL/GDI?

I don't know - I think OpenGL is probably easier to debug and develop for me personally because I can actually try it out in Linux. And of course, we potentially have the AllegroGL team to work with.

Raf256 said:

And how about adding the accumulating buffer then?

Maybe. Personally I'd need to think more about it and if it makes sense in a cross-platform setting. But the final word on that isn't mine anyway.

guilt said:

Well, we still gotta use DX for Input, anyway ...

Nope. I think we have input drivers for all Windows components that are independent of DirectInput.

guilt

Member #2,553

July 2002

Well... evert, but isn't the DI code faster than the Windows skirted IO approach?

[edit]
Ok, so if everyone's wantin to take up OpenGL, we can deprecate and remove the other drivers
[/edit]

Karthik Kumar Viswanathan

Website

Evert

Member #794

November 2000

guilt said:

Well... evert, but isn't the DI code faster than the Windows skirted IO approach?

No idea. You tell me.

guilt said:

Ok, so if everyone's wantin to take up OpenGL, we can deprecate and remove the other drivers

No, we can't. At the very least the plain X11 and GDI drivers must remain.

Raf256

Member #3,501

May 2003

The power of Allegro is
1) portability (cros-platform)
2) flexibility (work even with not-game configured computers)

Using either DirectX for 3D functions or skipping GDI,X11 takes that away.

I suggest to do as much as possible in OGL instead DX. Also in real-3d functions like 3d polygon.

IMHO allegrogl realy should be integrated into allegro core (4.3 ... 4.4 ?), and openlayer and some small GL engine (perhaps I would time to write one one day, of someone should go to allegro-pack (with aljpeg alpng \o/)

Peter Hull

Member #1,136

March 2001

DirectX has changed loads since the old WinAlleg days (don't we use DX3 in parts?) and it should be a lot easier using D3D9 I would say. The 'Lost Surface' thing is less of a problem (if you use the managed pool) for one thing.

AFAIK it's not possible to directly access the 'front buffer' though you can ask for direct access to the back buffer (I don't know if this imposes a speed penalty) If all else fails, you can copy the front buffer back into system memory (this would undoubtedly be slow...), alter it and write it back.

Also in D3D9 there's a mode which is conceptually like a copy from the back buffer to the front, which would suit Allegro very well.

Having said that, if it is possible to do everything in OpenGL, that might be better as we could develop for our three 'main' platforms at once, at least the graphics part.

Pete