Direct3D Accelerated AGS (beta 6) - Please Test

[Pumaman]

Oh, I see - then I REALLY must find out what makes the DirectX 5 engine crash my game when using the new .exe file.

I've just found a problem with the way the DX5 driver displays the preload graphic -- does your game have a preload.pcx? If so, try removing it and see if that stops the crash.
I'll fix the problem for the next version.

And yes, RawRestoreScreen() does seem to be the main issue. On second thought - is there anything that keeps the RawSaveScreen() image from being stored in the graphics card memory rather than in the RAM?

Once the image is in video memory, you can't get it back. In basic terms, video memory is generally write-only (it can be read but it's slow to do so). There are possible solutions to the RawDraw issue, but first I want to get this engine to a stable state.

Would weaker systems crash on even smaller screens than stronger systems?  This kind of uncertainty would make me nervous to use scrolling rooms.  I have a few larger rooms in my WiP.

With the current beta they would crash, but I'm going to have to code something in so that AGS creates multiple textures and splits the image across them so that you don't have to worry about it.

textures handling has been having very annoying restrictions for a long time (maximum size, dimensions must be a power of 2, etc.). I believe that texture size restriction has been removed only VERY recently, which could explain why this problem appears even on quite recent systems.

Yeah, these restrictions can be a pain in the ass. Having said that, personally I've only got on-board graphics on a 1.5-year-old motherboard but it supports 4096x4096 textures with no power-of-2 restriction, so things are improving.

[GarageGothic]

Yup, the preload.pcx was the problem. Thanks for solving it. I'm glad I hadn't started to commenting out pieces of code yet.

Re: RawSaveScreen - what if you kept it in duplicate, once in the video card memory, once in the RAM. RawRestoreScreen would then a) Copy the screen in video memory to the background texture in video memory b) Draw the saved background in RAM onto the "RawDraw buffer screen" in RAM. If, as you said, the texture in video memory isn't updated until the end of the game cycle, this would in most cases mean that it didn't have to be updated at all, since in many cases you RawRestoreScreen() after using RawDraw functions for things like these. And if the duplicate was kept in memory, there would be no need to read the screen back from video memory.

Edit: I located the problem of a black screen on startup. This was my full-screen black GUI which I use for fading effects. It seems that setting GUI transparency to 100 actually sets the transparency to 0 in the Direct3D engine.

[Pumaman]

Ok, beta 3 is up:
* Large sprites are now automatically split across multiple textures, so there should be no more "image too large" errors
* Fixed Alt+Tabbing away from the game not working with D3D driver (though it's still broken if you use PlayVideo)
* Fixed stuff with 100% transparency being drawn with 0% transparency by D3D driver
* Fixed crash drawing preload screen with DX5 driver
* Fixed 8-bit sprites going black with D3D driver

what if you kept it in duplicate, once in the video card memory, once in the RAM. RawRestoreScreen would then

This all sounds like a huge workaround, when it would probably be simpler to just implement RawDrawing onto dynamic sprites. It's something I'll look at for a future version -- in the meantime, if you must use RawDraw, you can just continue to use the DX5 driver.

[Recluse]

Is there any possibility of a few new graphics related functions coming about because of this?

Personally, I'd like to see particle effects and 3d models... I know it'd be way down the line, but could I get an indication of whether you're actually thinking of including such things?

[GarageGothic]

I get this when starting the 3D accelerated version of beta 3. It makes no difference whether I run windowed or not. DirectX 5 mode works fine.

---------------------------
Adventure Game Studio
---------------------------
An internal error has occurred. Please note down the following information.
If the problem persists, contact Chris Jones.
(ACI version 2.80.942D3D)

Error: Unexpected error occurred

---------------------------
OK   
---------------------------

Edit: To Recluse: If RawDrawing to sprites becomes possible, it will be quite easy to code a satisfactory particle system (not like the current modules that draw all particles behind the player).

Edit 2: Unlike joelphilippage I'm not using any plugins when getting this error message.

[joelphilippage]

I wanted to see if 3d acceleration would work with the 3d character plugin. It works using direct draw but when I  try to use direct 3d it shows this error:

Code: ags

---------------------------
Adventure Game Studio
---------------------------
An internal error has occurred. Please note down the following information.
If the problem persists, contact Chris Jones.
(ACI version 2.80.942D3D)

Error: Unexpected error occurred

---------------------------
OK   
---------------------------

Is this just a problem with the plugin?

[scotch]

It's probably too much to ask to make this compatible with the DX5 graphical plugins, which (although I've written a couple of graphics plugins) is a perfectly fine compromise as far as I'm concerned.

[Pumaman]

Is there any possibility of a few new graphics related functions coming about because of this?

Potentially, however I have no plans at the current time to add anything 3D-specific.

Error: Unexpected error occurred

Heh oops, sorry about that. Beta 3 crashes on startup if you have a gfx card that requires power-of-2 sized textures, it's fixed in beta 4.

It's probably too much to ask to make this compatible with the DX5 graphical plugins, which (although I've written a couple of graphics plugins) is a perfectly fine compromise as far as I'm concerned.

Well, as of beta 4 AGS will automatically exit if a plugin tries to access any DX5-specific functionality when you're using the D3D driver. As it happens the Character 3D plugin should still work fine, because it doesn't do that.

Anyway, beta 4 is now up. It contains the following:
* Implemented all screen transitions except crossfade
* Fixed beta 3 crash on startup with gfx cards that require power-of-2 textures
* Fixed pixel-perfect click detection with D3D driver
* Fixed DX5 driver leaving mouse cursor artefacts while in dialog
* Error message displayed if any plugins attempt to use DX5 driver functionality when running with D3D

[GarageGothic]

Ah, finally I can see the scrolling rooms. It looks good, and I've yet to encounter any more bugs. But my html module has slowed considerably despite only using RawDraw (mainly text) without RawRestoreScreen. I'm guessing this is due to the enormous size of the background (640x4000).

[Vince Twelve]

Hmm... I'm still getting the crash

---------------------------
Adventure Game Studio
---------------------------
An internal error has occurred. Please note down the following information.
If the problem persists, contact Chris Jones.
(ACI version 2.80.943D3D)

Error: Bitmap too large for texture memory

---------------------------
OK   
---------------------------

Perhaps my room is too large even for the work around you implemented.  The room is 19200 x 480.  Wow.  That's a lot larger than I remembered. 

[kid]

hi there

Adding  3d  to AGS is a great idea, but why Direct3D.
It wouldn't be beter to use OpenGL3D instead???.

OpenGl will make AGS  cross-platform with will increase community and mor popular.

I'm also suggest to use some cross-platform open source 3D engine like this one:

http://irrlicht.sourceforge.net/

[Misj']

Adding  3d  to AGS is a great idea, but why Direct3D.
It wouldn't be beter to use OpenGL3D instead???..

There's a difference between adding 3D (which I personally wouldn't consider useful for several reasons...) and adding the option to use the graphics-card 3D accelerator-chip to do 'complex' (semi-)2D calculations on your sprites (rotations, translations, stretches, etc).

While the latter might not add any functionality to the software as such, it could make certain graphical events faster (or not ).

Misj'

[scotch]

Yeah, but it would still be more friendly to the Linux/Mac version if OpenGL was used for the 3D acceleration purposes instead of D3D. It's virtually the same in terms of functionality to D3D, but is cross platform.

If it was based on OpenGL it'd port relatively easily to any OS, consoles, phones, handhelds, all kinds of things... being hardware accelerated on all of them.

As for Irrlicht, yes, that would be a bad idea, it's not relevant for AGS purposes.

[Shane 'ProgZmax' Stevens]

I think the main issue here is ease of implementation.  Right now it doesn't take a massive leap of coding for CJ to re-release the acwin with an updated directx functionality, whereas openGL would require him to implement an entirely new code framework and then allow people to choose between the two formats (unless he was just going to remove directx support altogether).  I think that's asking a bit much, in any case, and people should be pleased (I know I am) that he's upgrading the internal workings of ags at all.  I'm not CJ, though, so maybe he's up for it.

[Ali]

I might have missed this oddity being explained somewhere in the thread, but the DX9 version caused some odd colours on the configuration screen for Nelly Cootalot, which is a semi transparent GUI. The GUI appeared the wrong hue, as did the labels. I'm afraid I'm not on my home system so I can't post a screenshot.

Also, would this make anti-aliasing and smooth scaling together a realistic possibility at some point in the future?

[Pumaman]

Perhaps my room is too large even for the work around you implemented.  The room is 19200 x 480.  Wow.  That's a lot larger than I remembered.

Hmm, well spotted. This should now be fixed for beta 5.

OpenGl will make AGS  cross-platform with will increase community and mor popular.

AGS already is cross-platform. It may not currently support 3D Acceleration on other platforms, but that's not a major problem at the moment.

Yeah, but it would still be more friendly to the Linux/Mac version if OpenGL was used for the 3D acceleration purposes instead of D3D. It's virtually the same in terms of functionality to D3D, but is cross platform.

I chose D3D because I was already familiar with some of the API, and I already had all the necessary libraries installed to compile with it.
However, a lot of the work that I've done has been changing the main AGS engine to work with the restrictions of 3D hardware (eg. no direct access to screen, redrawing the whole screen each frame, etc), and so these changes mean that an AGS OpenGL driver would be much easier to write now if the need arose.

As for whether the need will arise, we'll see what benefit people get from D3D. If it's a success, then there'd be more reason to write an OpenGL version for the Mac & Linux ports.

I might have missed this oddity being explained somewhere in the thread, but the DX9 version caused some odd colours on the configuration screen for Nelly Cootalot, which is a semi transparent GUI. The GUI appeared the wrong hue, as did the labels. I'm afraid I'm not on my home system so I can't post a screenshot.

Hmm, you're right. What colour is the GUI itself? I notice that it comes out pinkish with 2.72, but more purpleish with D3D ... it might be that the two drivers handle transparency slightly differently.

Also, would this make anti-aliasing and smooth scaling together a realistic possibility at some point in the future?

I'd like to think so. So far I haven't found a way of enabling anti-aliasing for specific sprites in D3D -- it seems to be an all-or-nothing thing of having the whole screen anti-aliased or not, which obviously slows it down quite a bit.


Anyway, beta 5 is now up, with these changes:
* Implemented crossfade transition
* Implemented gamma control for D3D driver
* Fixed Ignore Walkbehinds setting not working in D3D driver
* Fixed rooms larger than 8000 pixels wide/high not working with D3D driver

As of this version, I consider the D3D driver complete. Please try out your games with this version of the engine, in both D3D and DX5 modes, and let me know if there are any problems.

[AJA]

Okay, I just tested The Heist with the beta5 engine. Here's a couple of things I noticed:
- Video playback doesn't seem to unload the codecs (or whatever) when they're done playing. (It just keeps opening new ffdshow tray icons.)
- The "letterbox black area" isn't black: at least guis and overlays are visible there.
- With the DirectDraw 5 setting the game hungs on startup and only shows a black screen.

[ciborium]

Just tries the new (beta 5) file.  DX5 works fine so far, but I get this error message with D3D:



My desktop is set to 1280x1024

The problem occurs whether I have the game set up to fullscreen or windowed.

[DoorKnobHandle]

Well, your 3d graphic card doesn't support pixel shader 1.4, without that, D3D won't run - atleast AGS won't. Seems that your card is a little outdated then.

[ciborium]

It probably is...  Nvidia GeForce 2

I just noticed that there seems to be a highlighted "garbage matte" around my alpha'd sprites that I didn't notice before while using the DX5 setting.  I'll post a pic later.

EDIT: I was unable to sucessfully capture an image where this occurs.  Even though I can see it in the engine, when I capture the screen, it is barely perceptible.  It is most noticeable in fullscreen, but only seems to occur at startup and the first couple of frames of walkcycle.  Then the "garbage matte" disappears.  I only have one room loaded right now, so I don't know what happens after changing rooms.  I may be able to mock-up  something to give you a better idea of what I mean.