Direct3D Accelerated AGS (beta 6) - Please Test

[Pumaman]

Having a 3D Accelerated engine has been something I've been looking at for a while, and I've now got something to the point where it would be useful to have your feedback on it.

What are you talking about?

I'm talking about a beta version of the AGS engine, that has Direct 3D acceleration.

What's the point? AGS games are 2D!

Modern graphics cards are optimised for 3D gaming rather than 2D games, which means that the 3D part of your graphics card tends to be faster than the 2D part. Also, features like alpha blending are built into 3D drivers and don't involve complicated CPU calculations like they do with a 2D system.

So how much better is it?

Well, that's what I want to find out. From my testing, it seems to be the case that:
* In a room that just has a background and the player character, the speed is about the same as the current engine
* In a room with some alpha-blended characters and objects, the 3D version can be 2-3x faster than the existing engine. The speed is faster when running full-screen than windowed.

Where can I get it?

Right here: http://www.adventuregamestudio.co.uk/acwin3dbeta6.zip

You'll need an existing version of AGS 2.72 or 2.8 installed. Open up your AGS Editor folder, rename your existing "acwin.exe" file, and place this one there instead. Then, rebuild your game.
Having done that, run the game setup and you should see a new option for whether to use Direct3D or DirectDraw (the standard AGS system).

In the game, you can press Ctrl+V to double-check which driver is being used.

Are there any known bugs?

* alt+tab stops working after using PlayVideo with D3D driver

I'm still looking into this.

What feedback do you want?

1. Does it work? Are you still able to play your games?
2. Are there any bugs? I've had to rework quite a bit of the engine, so I expect there'll be issues.
3. Is it any faster for you? If your game runs at 40 FPS anyway, you won't notice. But with this beta engine you can press Ctrl+E at any time, which will un-cap the frame rate and show it on the screen for you. Try this with both the D3D and normal options, and see if you get any improvement.

DO NOT DISTRIBUTE YOUR GAME WITH THIS VERSION OF THE ENGINE, IT IS JUST A BETA.

[monkey0506]

I don't really have a "game" per se, but I copied one of the folders I've been using developing scripts with the 2.8 Betas and the first thing I noticed was that: "Direct3D driver does not support 256-color games." So I had to up the graphics to 16-bit. Ordinarily when doing this the old (default) graphics still look fine, but all the cursors as well as Roger seem to have become solid black.

Also when I move the mouse up to the top of the screen, I can see the Windows cursor. It took me a bit to realize what I was seeing, but I could see the bottom of the window handle (running full-screen). I tried to click on the Exit button (default GUI) but the Windows cursor was present, took precedence, and brought me back to Windows (without closing the game). I tried to switch back to the game so I could exit it properly, but I was unable to and had to close the window manually.

-----

This isn't happening every time I run it, but it is only apparently occurring using the Direct3D driver.

-----

Other than that I noticed that I'm showing idling speeds of ~512 FPS. The thing that instantly occurred to me was that my version of the EncryptedFile module would be capable of encrypting/decrypting files at 512kBps with those FPS as opposed to the current 40kBps. That would make me happy.

Of course you'll probably get better feedback on any other issues from someone actually developing a game, mostly all my sample does is call some Displays and things. But the two issues I listed seemed relevant to #2 "Are there any bugs?"

Cheers

-----

I went ahead and tested my game using the old DirectDraw driver and both the issues I listed (with the 8-bit sprites converted to 16-bit being drawn black; and the top of the Window handle showing up allowing the Windows cursor to be seen/take control/screw things up) were resolved simply by using the old driver.

-----

However, even using the DirectDraw driver...I'm still showing in excess of 400 FPS...actually idling around 500...not quite as high as using the Direct3D driver...but significantly higher than the old acwin.

-----

One more thing (sorry about all the edits ), I don't know if it makes any difference, but I'm using 2.8 Beta 9.

[Dave Gilbert]

This is a GREAT thing, chris, and very much appreciated.   Having a few alpha-blended sprites in one room causes the current engine  to get very slow.  I'm going to test this out as soon as I can.

[Pumaman]

Thanks for your feedback.

Direct3D driver does not support 256-color games

Sorry, I forgot to mention that. It's a shame, but very few graphics cards support 256-colour in their 3D drivers. Having said that, if your game is 256-colour then it's unlikely that you'll be having any performance problems so using the normal driver should be fine.

Also when I move the mouse up to the top of the screen, I can see the Windows cursor. It took me a bit to realize what I was seeing, but I could see the bottom of the window handle (running full-screen).

Hmm that's strange, I don't seem to get that. What resolution were you running at?

However, even using the DirectDraw driver...I'm still showing in excess of 400 FPS...actually idling around 500...not quite as high as using the Direct3D driver...but significantly higher than the old acwin

Well, if you put  SetGameSpeed(1000);  into your game_start, you'd probably still get 400 fps with the old acwin.

The point of this is that even if your computer can run the game at the full 40 FPS, you can use Ctrl+E to see how much improvement D3D might make, so that someone with a slower PC who might only get 30 FPS with the current engine could benefit.

[GarageGothic]

NOTE: I didn't actually compile the game. I just ran the new acwin.exe in my game data folder, as I usually do when testing my game. Therefore you should probably take the comments below with a grain of salt.

I only tried it briefly, but I didn't see any framerate improvements in my 640x480 32-bit color game, despite using an anti-aliased player character. In fact, I get somehow worse performance for a couple of rooms. On the other hand, most of the effect stuff that sometimes slow my game down (dynamic shadows, lens distortion etc.) just use plain RawDraw routines.

EDIT: I looked further into this, and it seems that rooms that use RawDraw/DynamicSprites intensively have a 10 FPS lower framerate than when using the normal acwin.exe.

When teleporting to a very big room (a 640x4000 pixel black background), the game crashed with the message: "Error: Bitmap too large for texture memory". My machine is a laptop with a 128MB Radeon Mobility 9700 and 1 GB RAM.

Also, the game now starts with a black screen where only the GUIs are visible. I have to open another GUI (inventory, save menu etc.) for the background and character to show up.

If I select DirectX 5, the game crashes on startup with the message "An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x0047612F ; program pointer is -179, ACI version 2.80.940D3D, gtags (0,0)" for some reason.

[LimpingFish]

Using DX9 in conjuction with the panorama module at 640x480, 32-bit color, results in a 5-7fps framerate, considerably worse than the panorama's already sluggish framerate at the same settings.

It also seems to mess with the crossfade room transitions, as they simply aren't there. The screen just changes instantly.

Of course, this could be down to incompatabilities between the module and engine, rather than the engine itself.

[scotch]

Raw drawing and the like is often slower when you are working with 3d surfaces. For games that don't do pixel level operations there will be a massive speed up (if it was slow to start with), but if you're doing anything fancy... well... you may want to stick to the old methods. Perhaps some day when the 3d renderer is more established, some of the drawing can be exposed.

That "bitmap too large for texture memory" thing is a bit of an issue, though. What is the current limit? Many older/cheaper cards can't handle over 1024 pixels wide, and a background can easily go over that. Perhaps some splitting will be necessary.

Nice work so far though CJ, this is definitely worth it.

[Pumaman]

EDIT: I looked further into this, and it seems that rooms that use RawDraw/DynamicSprites intensively have a 10 FPS lower framerate than when using the normal acwin.exe.

Using DX9 in conjuction with the panorama module at 640x480, 32-bit color, results in a 5-7fps framerate, considerably worse than the panorama's already sluggish framerate at the same settings.

What Direct 3D is very good at is drawing pre-existing sprites to the screen very quickly (everything is just moved around inside the graphics card RAM, which is very fast).

However, it is quite slow at changing the content of sprites (because this involves moving data from the system memory into the graphics card).

RawDraw changes the contents of the room background, which comes under the latter.

Therefore, thanks for raising this because it's a very good point. With the previous AGS engine, RawDraw is not particularly slow and can be used in repeatedly_execute. However, with D3D if you use RawDraw regularly (eg. in a rep_exec function) it won't like it, and the game will run slower.

This sort of thing is where we need to discover what the optimal solution is. I'm not sure what you're using RawDraw for, but you might well find that just having an Object with the sprite in it is faster with D3D, whereas the RawDraw method is faster under DirectDraw.  

This is an interesting area to discuss, because it's the sort of thing where due to the very different nature of 3D to 2D, AGS can't shield you from the internals completely.

When teleporting to a very big room (a 640x4000 pixel black background), the game crashed with the message: "Error: Bitmap too large for texture memory". My machine is a laptop with a 128MB Radeon Mobility 9700 and 1 GB RAM.

Interesting point. 3D cards have a maximum sprite size, and it looks like 4000 pixels is too high for your system. It's something I can code around by internally creating two D3D sprites and splitting the background across them, but I wonder how widespread this problem will be.

Also, the game now starts with a black screen where only the GUIs are visible. I have to open another GUI (inventory, save menu etc.) for the background and character to show up.

Hmm, strange. Does anyone else get this?

If I select DirectX 5, the game crashes on startup with the message "An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x0047612F ; program pointer is -179, ACI version 2.80.940D3D, gtags (0,0)" for some reason.

Hmm, any chance you could upload the game that's causing this, or is it too large?

Using DX9 in conjuction with the panorama module at 640x480, 32-bit color, results in a 5-7fps framerate, considerably worse than the panorama's already sluggish framerate at the same settings.

The Panorama module uses a lot of RawDrawing, which is why it's slow. See earlier in this post.

It also seems to mess with the crossfade room transitions, as they simply aren't there. The screen just changes instantly.

This is listed in the "known issues" section in my first post.


Thanks for your feedback so far, guys. It'll be interesting to see whether there are many AGS games that actually benefit from this.


EDIT: scotch beat me to it about the RawDraw

[scotch]

I think the size issue will need to be worked around, there are even cards that won't take a 1024x1024 texture (mostly old PCI ones or onboard, at least).
Most new cards are ok on 4096x4096 but earlier geforce cards go up to 2048, older ATIs and onboard stuff up to 1024, many PCI 3d cards had a 512x512 or lower cap, but hopefully nobody is running those anymore.

I don't think it'd be too bad to have some graphics functions specific to each rendering backend, it seems unfortunately necessary if people want to take full advantage of things.

[LimpingFish]

This is listed in the "known issues" section in my first post.

Oops. Indeed it is. In the excitement of the moment, I missed it.  :

But it gives me a chance to ask a question.

What are the benefits of using DX9 over DX8.1? Are the problems that sometimes occur with DX9 (slower performance over DX8.1 on some GFX cards) applicable to the AGS engine? Or relevant to it's performance under Direct 3D?

[deadsuperhero]

Er, what about implementing OpenGL?
Then everybody could play the games made on your new engine.

[Shane 'ProgZmax' Stevens]

Here are some screenshots of Mind's Eye compiled under the new acwin @ 640x480x32:

Direct Draw (no noticeable speed increase)


D3D (again no noticeable speed increase)


Original


As you can see, there's some sort of weird widescreen effect in the new editor caused by loading a 320x240 screen at hi res, while the old acwin would just scale it up.  There's also cursor ghosting and some other issues.  The Mind's Eye intro, arguably the most ags-draining intro in existence, doesn't seem to run any faster at all and it uses (at last count) 6 full screen transparent overlays and 8 large transparent overlays.  I should point out that the intro always ran tolerably in low-res and runs no better under this acwin.  A few other things:

1.  In 320x240 the cursor ghosting goes away but the random sprite/object displacement seen in the first image persists.

2.  FadeIn/Out doesn't work properly with D3D on.  It just waits a bit and cuts to the next room.  I suspect this is just a minor incompatibility with the way Fade normally works since it doesn't cause a crash.

Having worked on D3D optimization before I can safely say you'll probably have to re-assess how the current engine renders (particularly transparency) and rework it to get much benefit.  Also, even though Dx 8.1 is outdated now it still has the superior 2D sprite renderer performance-wise, so you might consider trying a build for the hell of it.  Hope this helped, and if you have any questions or anything about ddraw stuff I can probably help.  I think it's great that you're trying to improve the speed for those of us who like to tax the engine a bit, so if I can help out by all means ask.

[Pumaman]

What are the benefits of using DX9 over DX8.1? Are the problems that sometimes occur with DX9 (slower performance over DX8.1 on some GFX cards) applicable to the AGS engine? Or relevant to it's performance under Direct 3D?

I've not heard of any claims of DX9 being slower than 8.1, do you have a source for that?

As you can see, there's some sort of weird widescreen effect in the new editor caused by loading a 320x240 screen at hi res, while the old acwin would just scale it up.  There's also cursor ghosting and some other issues.

Thanks, I'll look into these. Can you confirm that this only happens with the DX5 driver and not with D3D?

The Mind's Eye intro, arguably the most ags-draining intro in existence, doesn't seem to run any faster at all and it uses (at last count) 6 full screen transparent overlays and 8 large transparent overlays.

The main drain in the Mind's Eye intro is that you have a full-screen object that changes its tint every frame. This forces AGS to re-render the object every frame, which is slow.
Direct3D does support hardware acceleration of tints (which when I tried it out, puts the intro up from 10 fps to 45 fps on my machine); but the problem with it is that I haven't been able to replicate the same tint effect in D3D that you get in software mode. (AGS currently re-colourises the sprite, rather than just adjusting colour components with lighting, which is what D3D does).
Therefore, even when D3D is enabled, AGS still uses software mode for tinting because I'm unable to recreate the right effect in hardware mode. If you might be able to suggest a method for this with your D3D experience, that'd be appreciated.

2.  FadeIn/Out doesn't work properly with D3D on.  It just waits a bit and cuts to the next room.  I suspect this is just a minor incompatibility with the way Fade normally works since it doesn't cause a crash.

As I've said already, this is a known issue mentioned in the first post of this thread.

Having worked on D3D optimization before I can safely say you'll probably have to re-assess how the current engine renders (particularly transparency) and rework it to get much benefit.

As I say, the reason you're not seeing any benefit is because of the tinting issue.

Also, let's try not to be under the expectation that D3D will make everyone's game run twice as fast. In reality, whether you'll get any benefit depends on the type and size of sprites that you use. As we've seen, if you do a lot of Raw Drawing, you won't gain anything from D3D.

As an example of a situation where you see results, in my test game, which is a 640x480 room with 4 alpha-blended characters, D3D gives 410 FPS, whereas DX5 gives 150 FPS; which is a 2.5x speed increase.

[Shane 'ProgZmax' Stevens]

Thanks, I'll look into these. Can you confirm that this only happens with the DX5 driver and not with D3D?

As mentioned above, the two top pics are both 640x480x32 with the new acwin and both fail to scale the original game up to the new resolution.  The sprite displacement and cursor ghosting only occurs with the dx5 mode, however.

I've not heard of any claims of DX9 being slower than 8.1, do you have a source for that?

I know this question wasn't for me but I don't really need to cite a source other than myself, do I?  I had two builds of my engine, one that was using dx 8.1's ddraw routines for blitting and the newer, less specialized d3d blitting routines that use flat polys and the older routines were a bit faster.  I used to have some links to webpages with more detailed explanations for why this is but it's been about three years now and those bookmarks are all gone.  One of the major trade-offs, of course, is that with the old routines rotation and scaling are much slower and less precise than using a poly to handle the job.

Therefore, even when D3D is enabled, AGS still uses software mode for tinting because I'm unable to recreate the right effect in hardware mode. If you might be able to suggest a method for this with your D3D experience, that'd be appreciated.

Without having some source to look at I'd have to refer back to some of my books and think about it since I never tried adjusting colors on the fly with d3d.  Are you using the coloroperation variable out of curiosity?  One simple way I can think of altering tint (without taking into account blending beneath a sprite) is to adjust the tintRed/G/B values and then do a TextureOperation.Add on the coloroperation variable of the sprite to multiply those values against the existing sprite's RGB vals, effectively tinting it.  I think this is the most common way of doing it but I can't say for sure how fast it will be.  Obviously you'd need to store the tint values as separate variables that are altered by the existing tint functions in ags.  Was this helpful at all? ;\

[scotch]

AGS's HSV style object tint isn't possible with fixed function 3d, and since fragment shaders aren't going to be a safe option for some time, it'll have to be done the way it is, unless people accept a switch to a different blending effect. Probably the most likely candidate available is the ModulateX2 texture operation, because it lets you overlay colours, darkening and brightening, but it can't control saturation so it's not as useful.

3D based approaches are a lot faster than directdraw on my PC, but that will vary with the hardware.

[Shane 'ProgZmax' Stevens]

Something else I noticed in dx5 mode is that when you start dialogs all the objects, sprites and guis in a room are shut off temporarily.  They come back on as soon as the dialog finishes.  This does not happen in D3D mode.

[Gilbert]

As mentioned above, the two top pics are both 640x480x32 with the new acwin and both fail to scale the original game up to the new resolution.  The sprite displacement and cursor ghosting only occurs with the dx5 mode, however.

I noticed that your "original" screenshot was at 640x400 (I never played that game, I think its res was at 320x200 right?) while both new ones were at 640x480, that accounts for the "widescreen" effect, as the "scaling" done in displaying a "low-res" game in "hi-res" only doubles the pixels in both x and y directions, so the aspect ratio will be different when displayed fullscreen. I'm not sure but I think probably the new engine failed to use 640x400 (in both DirectX and Direct3D modes) so it forced the game to run at 640x480.

[Shane 'ProgZmax' Stevens]

It was definitely some kind of a glitch with opening the setup file inside of AGS.  It only had 320x240 and 640x480 available the first few times I tried it.  After a few reloads it let me pick 320x200 or 640x400 again (with the new acwin) and the effect was gone (along with the cursor ghosting in dx5 mode), but the screenshots prove it isn't just make believe.  It's probably some kind of setting in the new setup window that's not always accurately reading the game resolution.

[joelphilippage]

The sprites on Raven won't scale smoothly and some of the images alpha blending won't work.

[Gilbert]

Hmmm can you post a screenshot (it would be even better if there're two shots, one using old engine and one the 3D engine) showing the problem? I think this can help CJ nailing the glitches.