Direct3D Accelerated AGS (beta 6) - Please Test

Started by Pumaman, Sun 02/09/2007 17:45:12

Previous topic - Next topic

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

#1
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. ;D

-----

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.

QuoteDirect3D 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.

QuoteAlso 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?

QuoteHowever, 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

#4
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.
Steam: LimpingFish
PSN: LFishRoller
XB: TheActualLimpingFish
Spotify: LimpingFish

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

QuoteEDIT: 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.
QuoteUsing 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.

QuoteWhen 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.

QuoteAlso, 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?

QuoteIf 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?

QuoteUsing 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.

Quote
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

#8
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

#9
Quote from: Pumaman link=topic=32269.msg416875#msg416875
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?
Steam: LimpingFish
PSN: LFishRoller
XB: TheActualLimpingFish
Spotify: LimpingFish

deadsuperhero

Er, what about implementing OpenGL?
Then everybody could play the games made on your new engine.
The fediverse needs great indie game developers! Find me there!

Shane 'ProgZmax' Stevens

#11
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

#12
QuoteWhat 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?

QuoteAs 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?

QuoteThe 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.

Quote2.  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.

QuoteHaving 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

QuoteThanks, 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.

QuoteI'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.

QuoteTherefore, 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

#15
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

Quote from: ProgZmax on Mon 03/09/2007 00:22:47
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.

TheMagician

I think that adding D3D opens up many new possibilities.
However, as other people already mentioned I think this won't work without changes and/or additions to our currently existing set of functions with regard to the very different nature of 3D and 2D rendering.

Quote from: PUMAMANThis 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.

I use RawDraw for 80 percent of the special effects in my game (i.e. transparent moving water surfaces, particle effects like rain and snow) simply because the limit of 20 objects per room doesn't allow for anything else. Am I right that this limit still exists in v2.8?
If I remember correctly objects were limited to 20 per room because they used to slow down the engine? If now D3D solves this issue then perhaps the limit should be increased? I could then rewrite the code of my rain particle engine to see if it runs faster with objects instead of RawDraw particles.

And one final question: Would this change to D3D allow for higher resolutions of games (up to 1280x1024)? Because again I think this mainly wasn't possible because the CPU had to render everything?

mätzyboy

Sorry if this is completely out of scope for this discussion, and for not adding any input to the testing of the D3D engine but... Would this increase the chance for 3D characters to be incorporated in the AGS engine in a future edition? I know it can be achieved with Besh's plug-in, but I'm still curious...

scotch

It would make it more easily possible on one level (especially if plugin authors or script can get some access to the 3D context) but AGS is a 2D engine. Trying to impose 3D characters on top of gameplay code written for 2D rooms, hotspots, and so on, is very awkward. Anyone serious about doing a 3D game shouldn't really be using AGS or any of the other primarily 2D game engines. They're just not suited to it.


Pumaman

QuoteAs 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.

Ok, looks like the DX5 driver has some problems with letterbox mode. I'll take a look.

QuoteI 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.

If you're talking about DirectDraw, then that's what AGS already uses (and what it continues to use if you select the DX5 driver). I'm not aware of the DirectDraw routines in DX8 being any faster than those in DX5. In fact, DirectDraw was last updated in DX7 and is discontinued from DX8 onwards, with MS telling developers to use D3D instead for 2D games.

QuoteOne 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 can tint the sprites no problem; the problem is replicating the same tint effect that AGS currently does in software mode. As scotch says, this converts the colours from RGB to HSV, combines the HS from the source with the V from the destination, and then converts back to RGB.
I don't believe this is possible in D3D.

This tint issue is the main thing holding it back from being a fully accelerated engine, so I'd like to resolve it somehow. I guess it depends if people would be prepared to put up with a less effective tint in 3D mode.

QuoteSomething 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.

Interesting, I'll look into it.

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

As Gilbert says, please post a screenshot of a Before and After scenario. Your description is far too vague to investigate as it stands.

QuoteIf I remember correctly objects were limited to 20 per room because they used to slow down the engine? If now D3D solves this issue then perhaps the limit should be increased

That's a reasonable point, and something I'll certainly consider.

QuoteSorry if this is completely out of scope for this discussion, and for not adding any input to the testing of the D3D engine but... Would this increase the chance for 3D characters to be incorporated in the AGS engine in a future edition?

Potentially yes, however at the moment I have no plans to do so.

Pumaman

Ok, I've managed to get the HSV tinting working by using a custom pixel shader, however this would only work on graphics cards made for DX9.0a and later (which is basically cards made from about 2003/4 onwards).

I'm not sure if this is a reasonable minimum requirement to use the D3D driver, I guess I'll try and upload a version with this and see how many people it works for.

scotch

#25
It does seem unavoidable unless a very different tint effect was used. Most games don't use tinting though, so the pixel shader requirement would only be for games that do, right?

A lot of AGS game players will be on older hardware, perhaps the AGS effect can be cloned in PS1.1? Doing HSV conversion for each pixel seems to run out of temp registers (is that what's making it require PS2.0?) but since the tint is the same for the whole sprite you may as well precalculate that bit, set it as a vertex colour and scale it by the luminance of the sprite pixel, something like

Code: ags
sampler s0 : register(s0);

float4 main(float4 tint: COLOR0, float2 tex : TEXCOORD0) : COLOR {
	float amount = tint.a; // getting tint amount from the vertex colour alpha
	float4 pixel = tex2D(s0, tex); // supplied colour should be the RGB equiv of the HSL value, with 100% L
	float lum = dot(pixel, float4(0.299, 0.587, 0.114, 0)); // get lum from the image
	return tint * lum * amount + pixel*(1-amount); // scale the tint by the luma and blend it with the original sprite
}



the vertex colour supplied for object.Tint(are, g, b, sat, lum); would be HSLtoRGB(RGBtoHSL(are,g,b).h, 100%, lum) with the alpha set to sat. I might be way off the mark, but that looks similar to AGS's tint at a glance.

Edit: txt filter doesn't like "r"!

Shane 'ProgZmax' Stevens

That does look very similar, scotch.  You could do a quick internal check to see if a person's video card has the right hardware to support the new tinting method and switch between software/hardware rendering on the fly, that would eliminate the possibility of incompatibility issues altogether.

monkey0506

Quote from: ProgZmax on Tue 04/09/2007 06:10:56You could do a quick internal check to see if a person's video card has the right hardware to support the new tinting method and switch between software/hardware rendering on the fly, that would eliminate the possibility of incompatibility issues altogether.

I was going to mention something like that except 1) I have no experience in this field whatsoever and didn't really have a clue what I was saying and 2) I figured it was probably a pretty obvious solution to check "on-the-fly" if such a thing is even possible that I just felt dumb for considering suggesting it. :=

scotch

Yeah, that would be a better compromise.

GarageGothic

Is there any chance, that RawDraw could be implemented with a set of hybrid commands that allow the CPU to handle all RawDrawing in a screen buffer and only transferred to the GPU when actually displayed (at end of game cycle)?

I've spent 3 years coding different subsystems for my game (html module, dynamic shadows, lens refraction, even the custom dialog system), that all use RawDraw. Since they all operate by RawDrawing images or text onto the background, deforming and cropping the area and then grabbing it to a DynamicSprite, which may then be assigned to a character or an object, there is no easy workaround. It's really a shame if I can't take advantage of the hardware-accelerated engine, since my game is in hi-res using 32-bit, alpha channeled sprites which is exactly what it was made for.

Edit: Regarding the DirectDraw engine crashing on game-start, I'll see if I can isolate the problem and remove the game content that's not involved. Then I'll upload it.

Pumaman

QuoteA lot of AGS game players will be on older hardware, perhaps the AGS effect can be cloned in PS1.1? Doing HSV conversion for each pixel seems to run out of temp registers (is that what's making it require PS2.0?) but since the tint is the same for the whole sprite you may as well precalculate that bit, set it as a vertex colour and scale it by the luminance of the sprite pixel, something like

scotch, you're a genius, and I owe you a drink! :)
The problem was that I was calculating the HSV of the pixel colour in the shader, but since only the V is actually needed I've stripped out the H and S code, which now means it compiles with ps_1_4, which is DirectX 8.1. This means that it should run on graphics cards made from late 2002 onwards.

For the moment there's no software alternative, and I'm uploading beta 2 which will refuse to load with the D3D driver if your graphics card is too old, so that we can assess how many people it's likely to affect.

QuoteYou could do a quick internal check to see if a person's video card has the right hardware to support the new tinting method and switch between software/hardware rendering on the fly, that would eliminate the possibility of incompatibility issues altogether.

I'm not sure if there's any point. If the graphics card isn't made for at least DX 8.1, then its 3D capabilities are probably pretty shoddy, so the player would probably be better off just using the DX5 software driver.

QuoteIs there any chance, that RawDraw could be implemented with a set of hybrid commands that allow the CPU to handle all RawDrawing in a screen buffer and only transferred to the GPU when actually displayed (at end of game cycle)?

It does that already, but 3D cards *really* don't like you changing the data on their textures. If you're using anything like RawRestoreScreen, RawDrawFrame, etc then the whole background needs to be updated, which means updating a significant amount of texture data each frame, which is bound to cause it to run slowly.

QuoteI've spent 3 years coding different subsystems for my game (html module, dynamic shadows, lens refraction, even the custom dialog system), that all use RawDraw. Since they all operate by RawDrawing images or text onto the background, deforming and cropping the area and then grabbing it to a DynamicSprite, which may then be assigned to a character or an object, there is no easy workaround.

It's only if you RawDraw every frame that you'll notice the slowness. It's fine to construct some dynamic sprites by using raw draw, just as long as you don't do it on every game cycle.


Anyway, beta 2 is now up. This has the following changes:
* Implemented hardware accelerated tint
* Fixed walk-behinds not working in scrolling rooms
* Fixed letterbox mode with DX5 driver

I've also updated the Known Bugs section in the first post with the reported issues.

With this new engine's hardware tinting, the Mind's Eye intro goes from 10 fps to 50 fps on my machine.

Shane 'ProgZmax' Stevens

Nice work, CJ.  Shame I couldn't be of more help on this occasion.  At any rate, maybe a comparison of fps ratings using the AGS internal counter will be of some use.

First the original acwin @ 320x200:



and @ 640x400:




And now the new acwin using the dx5 setting @ 320x200:



and @ 640x400:




And finally d3d mode @ 320x200:



and 640x400:




First I'll say that these fps ratings were either taken as the average (in the case of the dx5 and original) or at a constant rate (the d3d values remained stuck at 40 regardless).

The main thing I noticed (aside from clearly not having as good a rig as you do) is that the original actually rendered the high res title screen faster than the newer acwin.  I thought perhaps the dx5 mode was just a carry-over from the old acwin but there seems to be some difference there. 

Both modes clearly outperform the old method in every case except 640x400 vs dx5, and after several retests it seems pretty clear that the old acwin has a 4-8 fps advantage in this mode over dx5, which is weird (but not large enough to worry about, I think).

Overall this new version yields considerable bonuses -- particularly at larger resolutions.  Excellent work!




SSH

I think this RawDraw issue highlights the need for being able to RawDraw onto sprites, or some kind of temp screen that isn't going to be displayed. Would rawdrawing onto a DIFFERENT background (i.e. switch BG number to one of the 2-5 other BGs) then switching back speed things up?
12

scotch

I can see a slight advantage to that, but like CJ said, this is only a real problem if you're doing a lot of big rawdraws every frame. In the kind of situation you might predraw some static things in another room it's going to be barely noticable.

Rawdrawing onto sprites sounds more useful, GarageGothic's hack of drawing to the screen then capturing that to a sprite sounds a little messy.

Pumaman

Quotethe d3d values remained stuck at 40 regardless

That's probably because your game speed is set at 40 fps. You can use the Ctrl+E key in the new engine to un-cap the game frame rate if you want to see how much your computer can manage.

Quotethe original actually rendered the high res title screen faster than the newer acwin.  I thought perhaps the dx5 mode was just a carry-over from the old acwin but there seems to be some difference there. 

Although the dx5 mode is just a carry-over from the old acwin in spirit, I've had to make a lot of changes to AGS in order to make the graphics rendering compatible with the way that 3D engines work. Therefore, I've had to re-jig a lot of the 2D code as well, which is why we're seeing bugs in the DX5 driver that weren't there in the old acwin.
Hopefully, by testing out this new engine as we are now, it'll allow us to find the problems early on.

QuoteI can see a slight advantage to that, but like CJ said, this is only a real problem if you're doing a lot of big rawdraws every frame. In the kind of situation you might predraw some static things in another room it's going to be barely noticable.

I'd be interested to see a few example cases of where people are RawDrawing on every game cycle. Perhaps there's a faster way?

QuoteRawdrawing onto sprites sounds more useful, GarageGothic's hack of drawing to the screen then capturing that to a sprite sounds a little messy.

I completely agree, it's something that I've been meaning to do for ages. Hopefully I'll get round to it soon ;)

GarageGothic

#35
QuoteI'd be interested to see a few example cases of where people are RawDrawing on every game cycle. Perhaps there's a faster way?

Here's a few examples of that from my game.

Dynamic Shadows (please disregard the pre-rendered shadow of the horse):


Arguably, this could be done without RawDrawing, but it would be a pain in the ass. The shadow module crops the floor,wall and ceiling shadows according to predefined wall lines by RawDrawing the geometry using RGB(255,0,255). The only workaround that I can think of would be to define detailed walkbehinds for every single room that uses shadows. This is not a satisfactory solution.

Edit: Oh, I just remember why it can't even be done with walkbehinds. You'd have to make sprites of every single floor surface, which is even worse

Optical effects:




These are examples of a couple of lens refraction effects. They use RawDrawing for 1) compositing many differently scaled pieces into one single sprite and 2) for cropping the DynamicSprite to a non-rectangular shape. I don't think there's a simpler (or even any other?) way to do this.

I think RawDrawing to sprites is a great idea, especially if it can help on the Direct3D situation since it would mean not having to use RawRestoreScreen every loop (which - to be - honest, even simple RawDraw effects like the dog leash in Blackwell Legacy needs). For my purposes the SpriteRawDraw would need to support all the same functions as the current RawDraw routines, and it would be nice with a few more (for instance copying the alpha channel of an existing sprite to a DynamicSprite of the same size).

Edit: Will the new DirectX 5 mode replace the current graphic rendering in future versions of AGS? I really hope I won't be stuck with 2.72 for my future games  :-\

Pumaman

QuoteThese are examples of a couple of lens refraction effects. They use RawDrawing for 1) compositing many differently scaled pieces into one single sprite and 2) for cropping the DynamicSprite to a non-rectangular shape. I don't think there's a simpler (or even any other?) way to do this.

Interesting, thanks for the examples. I guess the main problem is the fact that you're having to use RawRestoreScreen that's causing the slowness, if you were able to RawDraw directly to a sprite then this probably wouldn't be such an issue.

QuoteEdit: Will the new DirectX 5 mode replace the current graphic rendering in future versions of AGS? I really hope I won't be stuck with 2.72 for my future games

I don't really understand the question. The new DX5 mode *is* the same as the current 2.72 rendering.

GarageGothic

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

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?

Vince Twelve

Quote
QuoteWhen 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.

I was going to try this out on Linus which was also a system chugger, but I had this same problem.  For the intro and ending, I used a room that was 10 or 12 screen widths wide and moved the viewport down the room using each 640x480 block as a frame of animation.

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.

Monsieur OUXX

#39
Quote from: Vince Twelve on Thu 06/09/2007 01:22:13
Quote
QuoteWhen 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.

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.

AFAIK, this problem doesn't come from the "strength" of the system (at least, not from the processor/ram combo); this would be exclusively a graphics card issue, since 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.

Nevertheless, i'm a bit surprised that this hasn't been "workarounded" by some kind of software - there ususually is a mad guy who codes the appropriate library to solve the harware limitations (i'm not talking about the AGS community, I'm talking about the OpenGL/DirectX communities). Maybe this kind of library didn't come in a consensual version, which would explain why it is not directly integrated in every rendering engines?
 

Pumaman

QuoteOh, 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.

QuoteAnd 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.

QuoteWould 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.

Quotetextures 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

#41
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

Quotewhat 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?
All your verbcoin are belong to us.

GarageGothic

#44
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.

Quote---------------------------
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

QuoteIs 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.

QuoteError: 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.

QuoteIt'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

#48
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

Quote---------------------------
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'

Quote from: kid on Mon 10/09/2007 17:21:33
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

#52
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

QuotePerhaps 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.

QuoteOpenGl 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.

QuoteYeah, 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.

QuoteI 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.

QuoteAlso, 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

#59
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.

DoorKnobHandle

Yep, how old is a GeForce 2 now? Close to ten years? That's a bit too old, I guess. :=

Ali

Quote from: Pumaman on Tue 11/09/2007 21:54:20
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.

The GUI was maroon with DX5 and came out a An indigo/violet hue. The labels became cyan rather than magenta.

Quote from: Pumaman on Tue 11/09/2007 21:54:20
QuoteAlso, 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.

I know nothing of Direct X, but rather than having genuine full screen anti-aliasing, couldn't it be achieved through alpha-blended sprites as it is now, but with smooth scaling? That's probably nonsense, so I'm sorry if it's a stupid question.


scotch

#62
"I know nothing of Direct X, but rather than having genuine full screen anti-aliasing, couldn't it be achieved through alpha-blended sprites as it is now, but with smooth scaling?"

Yes, you're basically right, there's no need to do FSAA, the alpha + smooth scaling approach should work right. And of course scaling + alpha channel is nothing for 3d hardware. FSAA doesn't help much on sprites anyway, it's meant for reducing jagged edges on geometry by supersampling. On a sprite there's nothing to supersample at 100% or greater, and at lower MIPmapping is a fast, and often better effect.

3D apis will autogenerate mipmaps and texture filtering on a per texture basis, so it's easy to have the "Smooth scaling" option in setup govern that.

Edit: Yeah a Geforce 2 is old, but it's fairly powerful and should run games in D3D a lot faster than software mode, if the shader was optional.

Pumaman

Quote- 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.

Thanks for the reports, I'll look into these.

QuoteI 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.

Hmm, strange. Are these alpha-channel sprites or do you mean the scaled sprite anti-aliasing?

QuoteI know nothing of Direct X, but rather than having genuine full screen anti-aliasing, couldn't it be achieved through alpha-blended sprites as it is now, but with smooth scaling? That's probably nonsense, so I'm sorry if it's a stupid question.

Well yes, and scotch seems to be saying that it's possible; I just haven't worked out how to do it. I'll need to rummage through the D3D API some more.

ciborium

They are alpha channel sprites.  My artist is making 3d sprites like the ones in Al Emmo.  If I can get a good screen capture, I'll post it.  But so far, no luck.

Pumaman

Hmm, well I had a look at some alpha-channel sprites and I couldn't see any problems. If you can get a screenshot, please do post it.

Quote- Video playback doesn't seem to unload the codecs (or whatever) when they're done playing. (It just keeps opening new ffdshow tray icons.)

Hmm, I don't get this behaviour, but I've twiddled a bit with beta 6, is it any better now? Also, do the tray icons disappear when you quit the game or do they remain forever?

Quote- With the DirectDraw 5 setting the game hungs on startup and only shows a black screen.

Hmm, I tried this but it was fine. Do you get this every time?

Beta 6 is now up, with these changes:
* Implemented smooth scaling on D3D driver (using the same option in Setup for smooth scaled sprites)
* Fixed colour corruption on preload screen with DX5 driver
* Fixed graphics spilling over into letterbox borders with D3D driver
* Fixed D3D color corruption on some systems when returning from alt+tab

AJA

Quote from: Pumaman on Sun 16/09/2007 14:56:20
Quote- Video playback doesn't seem to unload the codecs (or whatever) when they're done playing. (It just keeps opening new ffdshow tray icons.)

Hmm, I don't get this behaviour, but I've twiddled a bit with beta 6, is it any better now? Also, do the tray icons disappear when you quit the game or do they remain forever?

I played the game through once and this is what the tray looked like:


After the game is closed the icons disappear when you move the mouse cursor over them. So it's not a big deal but a bit annoying. (The ones with black "text" are video filters and the ones with cyan text are for audio.)


Quote
Quote- With the DirectDraw 5 setting the game hungs on startup and only shows a black screen.

Hmm, I tried this but it was fine. Do you get this every time?

It doesn't seem to have anything to do with the D3D engine since the same thing apparently happens with the old 2.71 engine also. So, I guess my there's a problem with my video codecs... (DivX works, XviD hangs works when DivX is uninstalled, libavcodec hangs.) With the D3D engine, however, CPU usage goes up to ~98% while playing a video (doesn't seem to depend on the decoding codec) and the playback is really choppy.

-edit-
The playback goes back to smooth when I play the game windowed and give focus to a different window. Weird.

Pumaman

Hmm, sounds like your problems are mainly due to using a dodgy codec. I tried out The Heist and the videos didn't play properly either; I'd recommend using a better supported codec (eg. standard XVid rather than something that relies on ffdshow) in future.

As for the smoothness, that should be fixed in 2.8 beta 10, see below:

------

Thanks for all your feedback with this new D3D engine guys, I think now is the time for me to merge it into the main 2.8 distribution. Therefore, this thread is now closed. Any further discussion, please use the 2.8 beta thread:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=31519.0

SMF spam blocked by CleanTalk