Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / [STICKY] DX11 Plugin

Author
Message
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Apr 2016 11:46
Quote: "Ah, was that it then? At least easily solved and the error messages would make sense then!"


Indeed it was.

Quote: "Maybe I should add a function to show the name of the currently used graphics adapter (or let you choose one for your program without having to change the default one for that matter)."


Yes, please! At the moment I have the Intel card as the default GFX card - because it's annoying to have the "high performance" fan noise all the time when it isn't needed (and some old games will not run correctly with the Nvidia "high performance" card ). I can set the defaults for individual programs and games but not, as far as I can see, for a group of exes such as all DBP executables or a subset of them. So at the moment I have the hassle of compiling your demos in the editor then running them outside the editor with the Nvidia card (when I remember ). I know Lee mentioned this as a possibility for GameGuru but I have no idea whether or not he implemented it. So if you could add a simple function enabling the programmer/user to choose that would be extremely useful - and not just to me I'm sure.

Incidentally, the Windows 10 SDK fixed the problem with the Visual Studio demos.

All I need now is some time to actually do something useful with all this.


Powered by Free Banners
James H
12
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 3rd Apr 2016 12:54
Quote: "It doesn't; DirectX 11.0 runs perfectly fine on Windows 7"

Now its me that's embarrassed, I have even played Battlefield 4 in dx11 on win7 before I upgraded to win10!!!! Pretty sure it ran fine in 32 bit as well...besides DBP is 32 bit and your demo's work fine. I was stupid enough to just google it and read 1 result from MSDN, which on second look was specific to xbox kinect! That's what I get for responding when tired, worse still the second result from google detailed in the first line of the description that it runs on win7, couldn't have failed more epically - well am sure I will find a way in the future

Quote: "However its license seemed to indicate that it was free for personal use only"

Um I don't see the mention of personal use anywhere in the license or indication of it, the way I interpret it is basically that the first part says you have permission to do with it as you see fit, including selling, so long as the conditions of the second part are met - a) the license is packaged alongside it and b) you can't hold the author responsible for anything related to it in general. At least that 's the gist of what I read. Is there some legal jargon there I am misinterpreting? Perhaps the license has changed since you last looked at it? Or maybe the author is not Cedric Guillemet and is just claiming to be? I know less than zero about these things so am pretty curious is all - besides I had figured you had already gone so far down the rabbit hole so to speak and would want to finish what you started, I kind of meant for you to maybe use the link within as a guide of sorts to help you speed up the process, I only linked to the DBP forum link as I wouldn't want folks thinking I was pretending to know about the link within, when the only reason I know about it was because of Hotline's post, there is mention of it being OpenGL fixed pipeline but a little later this is mentioned which I felt was where you where heading:

" You can implement those methods using any API. There aren't any other call to a rendering library anywhere
else. There is an old (untested) version using DX9 api.

********************************************************************************************************
* TODO

- Linux/MacOSX port
- Code cleanup
- improve example with local/world/screen space change
- DX10/11 rendering"
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Apr 2016 14:06
James H: Be reassured. You are not alone. Perhaps my difficulties are catching?

Rudolpho

I've just been testing your DLL and noticed an oddity with exe sizes.

After installing your DLL my exe sizes have increased dramatically after a new compile - even when they don't use your DLL. For example, a dice game I made a few years ago has increased from 4.782 MB to 9.315 MB. (In contrast the same game compiled using DBP Open Source (DBPOS) has reduced in size, i.e. to about 4.041 MB. Unfortunately, the DBPOS version doesn't run correctly so as usual you can't have everything I suppose. )

I've tracked the increase in size down to the presence of your "md5.dll" in the Compiler directory - when I replace that with the original DBPro version, the exe size for my game returns to its original value. Also, your demos still compile and run using the original DBPro version. The only change I noticed during execution of your demos was that certain error messages (such as when I used the wrong GFX card - sad but true ) were shorter or absent. Your exe files were slightly smaller too - but only about 20 K bytes smaller.

Any idea what's going on? An increase from 4.782 MB to 9.315 MB is hard to swallow.


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 3rd Apr 2016 16:12 Edited at: 3rd Apr 2016 16:17
@Green Gandalf:
That is good to hear
Adding enumeration functionality for available graphics cards shouldn't be that hard to do; I'll add it to my ever-growing list of things to do for the release of 0.5... I just hope I can exhaust said list and actually get it released sometime!
And for once, something good that was included with Windows 10 and that weren't with Windows 7 then; I recall having to find, install and manually link to that thing back when I first started out with this project. Glad to hear it's working for you!

@James H:
Haha, don't worry about that; who doesn't get things mixed up every once in a while.
As for the license issue it's been a while now; maybe I just misinterpreted it (usually if something is ambigious to the degree that I can't say what it means for certain it seems the safer bet to just assume it's off the table).
That thing about having to include the license agreement rings a bell though - that is a tricky thing since I assume that it by extension means that all programs using my engine would then have to include said license agreement as well. And it would be quite difficult to hold people to making sure to include a dozen or so different README's with every small DBPro program they make and put up for downloading somewhere. Of course I could probably write some terms-of-use document myself that states that I'm not responsible for what users of my engine do or don't on that front but in all honesty I certainly can't write a legally sound such document myself and I won't ask (pay) for help doing it until version 1.0 is ready to go.
Currently there is a license agreement for the Assimp library that is included as a resource in the dll file itself; this should be good enough for that particular library as its agreement stated something along the lines of "this text has to be included". But legal stuffs are by definition finicky and I wouldn't be surprised if the wording "this file has to be included" unquestionably means that the literal text file must be supplied alongside the executable / dll.
But as said, it's entirely possible I got that agreement wrong and could in fact have used it after porting it to use DX11 for drawing. And yes, I'm certainly too far down the rabbit hole to change to that now

Green Gandalf wrote: "I've tracked the increase in size down to the presence of your "md5.dll" in the Compiler directory - when I replace that with the original DBPro version, the exe size for my game returns to its original value."

Indeed, the MD5 mod isn't particularly elegant; it will be replaced sometime in the future, either by a rebuilt Compiler.exe or another means.
In any case, the MD5 mod has two purposes:
• It hotpatches DBPCompiler.exe to allow reading more than 1000 string table entries per dll.
• It injects additional function calls in your to-be compiled code that keeps my plugin aware of line numbers and source file names to better report where an error occurred.

The hotpatching is the only "necessary" feature here; without this most functions are available, but there are ~80 that go beyond the arbitrary limit of 1000 functions / dll. As such you cannot call any "new" functions without the MD5.dll hack. Since most functions (all from versions earlier than 0.4.7.5) are below the id-1000 mark, all of the currently available example projects will work without this. As the engine grows and the dll function count grows in the future this problem will get more and more apparent though.

What causes the file size issues is the other feature of the modified MD5.dll.
As mentioned, additional function calls will be added to your source code - these functions all reside in DX11.dll, which means it will be included and add its ~4.4Mb to your final executable size.
I should probably make it search for function calls to DX11.dll and only add these calls then, but as for now you should be able to use this precompiler directive at the top of your source to disable the code injection:
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Apr 2016 17:07
Quote: "but as for now you should be able to use this precompiler directive at the top of your source to disable the code injection:"


Thanks! That fixed it. Now I can safely recompile my projects with your DLL intact.

Thanks also for the explanations. Much appreciated.

Just been browsing your Help files. You've obviously done an enormous amount of work on this. I hope it comes to fruition. In fact it looks like you are very close to creating an entirely DX11 version of DBPro!


Powered by Free Banners
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 3rd Apr 2016 18:26
Interesting idea with the object transformation gizmo. I am not a gizmo fan, talking from a 3D modelling and architectual standpoint, the easier to develop and more time efficient method of just assigning hot keys along with mouse drags appeals to me.

But it is still a good idea because some people like transform gizmos; to each their own.
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 4th Apr 2016 11:18
@Green Gandalf:
That's good to hear and thank you very much
Yes, it has been quite some work, and there'll be some to go yet. The help files in particular take their time, though I wrote a small "docgen"-like parser that speeds up the process a lot. Basically it goes over my source files for the respective function sections used when building the dll and interprets block comments like these and put their contents into a template HTML file:


@Chris:
They have their advantages and disadvantages for sure. Still, they provide a very hands-on tool and are a bit more aesthetically pleasing than "Hold R to rotate" etc. Furthermore, "directionality" is taken into account more easily; there would be a lot of keys to facilitate moving along cardinal axii as well as dual axii, rotating, scaling etc. In any case, it's just going to be there as an option, not something that has to be used. I personally plan to use it in some demo projects for easily moving stuff around to demonstrate shadow casting based on object and light source orientations etc. It's also reusable for future demo projects, allowing me to keep the code of those more focused on what the project is actually meant to demonstrate rather than a lot of movement code.
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 4th Apr 2016 12:20
Quote: "Basically it goes over my source files for the respective function sections used when building the dll and interprets block comments like these and put their contents into a template HTML file:"


Sounds very organised and professional.


Powered by Free Banners
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 4th Apr 2016 16:57 Edited at: 4th Apr 2016 16:59
Quote: " they provide a very hands-on tool and are a bit more aesthetically pleasing than "Hold R to rotate""


Very definately, you know the big picture. Any type of transform gizmo is a bonus to have in a game engine. I just made the point because I've not used transform gizmos for 5 years now after about a few 1000 drags I kind of got fed up; and so kind of avoid tools which focus on its use, but you state that its optional so I have nothing to fear; they do look cool, and indeed keyboard+mouse combos are not for everyone.

I look forward to seeing the demos.

By the way do you mean cardial axes? I must be mistaken, you mentioned axii which is more related to the Witcher 3 than 3D geometry, is it not.
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 4th Apr 2016 19:27
Rudolpho

I've noticed that I get an error message when I try to run your demos with DBPro Open Source (see attachment), but they run fine if I reinstate the original "md5.dll". I recall seeing some discussion of running your plugin but can't recall what was said or where, so sorry if I'm repeating this.


Powered by Free Banners

Attachments

Login to view attachments
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 4th Apr 2016 20:56
@Green Gandalf:
The MD5 mod was written before DBPro went open-source, ie. there was only one compiler binary to support (actually it uses pattern scanning and at the very least support both the official U76 and RC77 compiler builds).
When the compiler is recompiled (as funny as that sounds), using a different environment and perhaps some tweaked code as well, these memory patterns may not be present anymore. I assume this is what has happened here. Basically it cannot find the memory address to overwrite in DBPCompiler.exe.
On the plus side; as you have access to the compiler code you can easily change the 1000 functions-per-dll limit and recompile it yourself. Doing that will allow you to use all available functions without the need for the modded MD5.dll. Of course this means there'll be no error line reporting instead.
I suppose I will have to try to come up with a new approach to support all possible rebuilt compiler versions. Maybe a separate precompiler-type application that gets called before the actual compiler would be portable and non-intrusive to work with?

Chris wrote: "By the way do you mean cardial axes? I must be mistaken, you mentioned axii which is more related to the Witcher 3 than 3D geometry, is it not."

Oops, it would appear you're right... I thought it went "one axis, many axii" but apparently not then. Not sure where I got that idea now... hm... embarassing
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 4th Apr 2016 21:13
Quote: "On the plus side; as you have access to the compiler code you can easily change the 1000 functions-per-dll limit and recompile it yourself."


If only I knew how to do that. Although I have VS 2010 I don't know enough (i.e. anything ) about it to deal with problems. For example, I couldn't even work out how to open some of the project files today, some open but others just do nothing when I try to open them.


Powered by Free Banners
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 4th Apr 2016 23:48
You probably know all this:

I've just been playing with your demos using DBPro Open Source and they all work using the DBP(OS) version of md5.dll with only minor changes to the code. The changes all concerned your occasional use of the Matrix1 utilities:

1. I had to replace the log() function with my own custom natural logarithm function written before IanM added the function to his utilities:



2. Replace the crlf$() calls with the obvious CHR$() calls.

I find this very reassuring - for both DBP(OS) and your DX11 Plugin.

I had two questions about the examples whichever compiler I used

Q1. In the particles demo I couldn't see the checkerboard floor object. Should I have done?
Q2. The display in the screen quad demo continually flickered very alarmingly. Was that supposed to happen?


Powered by Free Banners
Ortu
DBPro Master
11
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 4th Apr 2016 23:57
I agree with the others, this is the up at the top of the most exciting projects in a long time. it started off as a bit of a curiosity, but is steadily becoming what I think a lot of people were hoping dark basic elite could have been.

With DBPOS, could the dependency on dx9 be removed?
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 5th Apr 2016 00:21
Quote: "this is the up at the top of the most exciting projects in a long time. it started off as a bit of a curiosity, but is steadily becoming what I think a lot of people were hoping dark basic elite could have been."




Now let's hope some of us start to do something with it.


Powered by Free Banners
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 5th Apr 2016 02:18
@Rudolpho

I think some people pronounce the plural form axes as you wrote it (axii) with a quiet 's'. So that may be why; no big deal.
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 5th Apr 2016 19:03
Green Gandalf wrote: "Although I have VS 2010 I don't know enough (i.e. anything) about it to deal with problems."

Haha yes it is quite the behemoth to take on in the beginning, however I would say it is well worth investing some time into getting accustomed with it. Once the inevitable cascade of linker errors clears up it can be quite a handy tool.
Also you generally want to open the solution files (.sln) rather than the project files (.vcxproj) directly; furthermore the solution files are not uncommonly found in the parent folder to where the project files reside, if that may help.

Green Gandalf wrote: "I had to replace the log() function with my own custom natural logarithm function"

That's quite an impressive function! Good job. It's still hard to see why DBPro doesn't provide its own logarithm functions though...

Green Gandalf wrote: "Q1. In the particles demo I couldn't see the checkerboard floor object. Should I have done?"

I had completely forgotten that there even was supposed to be a floor object there. That is an error on my part; on line 316 the floor object is rotated 90 degrees around its X-axis, but it should be 270. When rotated 90 degrees the back-face will be facing upwards which means it won't be drawn.
Good find!

Green Gandalf wrote: "Q2. The display in the screen quad demo continually flickered very alarmingly. Was that supposed to happen?"

This isn't something that I've experienced no. What framerate are you getting with this project?
The whole screen quad example was very quickly thrown together as I recall, using the simplest kind of post-effect I could think up. As such some error may have snuck in there; looking at the code I cannot find anything obviously wrong with it though.
The text display does flicker a bit as the displayed values continuously change, but apart from that I get a smooth, blurred picture as intended on my machine. Could you perhaps record a short video of the issues you're experiencing?

@Ortu and Jim: thanks guys!
Ortu wrote: "With DBPOS, could the dependency on dx9 be removed?"

That should certainly be possible.

Chris Tate wrote: "I think some people pronounce the plural form axes as you wrote it (axii) with a quiet 's'. So that may be why; no big deal."

Hm yes that may be... I seem to recall being corrected on this (or possibly another, similar word) in the past too though now that you mentioned it. Oh well, guess I have some documentation entries to edit then
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 5th Apr 2016 20:26
Quote: "but it should be 270"


Thanks! That fixed it.

Quote: "Could you perhaps record a short video of the issues you're experiencing?"


I'll try to if necessary. However the effect is easy to describe: it alternates rapidly between a pure black image and the attached image. According to that image the FPS is about 67. I had to alt+PrtSc a few times to capture both. It's as if the black screen is being displayed when it should be hidden behind the scenes.


Powered by Free Banners

Attachments

Login to view attachments
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 5th Apr 2016 20:56
Hm... that image looks like what it should draw with the shader on the image rendered by the first camera.
You can try to set the background colour of camera 1 to something that will stand out a bit (line 27) and see if that gets drawn instead of the black screen then.
You can also try to set the sync mask to zero (line 112) and see if it will still draw anything then. The render target of camera 1 shouldn't be drawn to the screen but if this is what's happening there may be a bug somewhere in there.

Quote: "According to that image the FPS is about 67."

And I who thought my 650 was bad. My blur shader must be really inefficient
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 5th Apr 2016 21:29
Quote: "And I who thought my 650 was bad. My blur shader must be really inefficient "


I'm using my laptop for everything till I get my main machine repaired/replaced so that might explain it.

Quote: "You can try to set the background colour of camera 1 to something that will stand out a bit (line 27) and see if that gets drawn instead of the black screen then.
You can also try to set the sync mask to zero (line 112) and see if it will still draw anything then. "


I'll have a go and report back tomorrow.


Powered by Free Banners
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 6th Apr 2016 12:18 Edited at: 6th Apr 2016 12:51
Rudolpho

I've been doing a bit of experimenting and reading your help files in an attempt to understand what line 112 is doing. Here's line 112:



If I have understood things correctly, the main camera id is just 0 so the bit shift operation doesn't actually do anything so commenting out the bit shift part should have no effect which is what happens.

If I change line 112 to



I just get a black screen which I guess is because the shift operation stops camera 0 from being rendered and is what I would naively expect. I guess that means the problem is somewhere else. Or have I misunderstood?

I tried changing the backdrop in line 27 to red instead of black and got a flashing bright red image alternating with the black screen instead of green alternating with black. Is there a simple way of delaying the renders to something like one or two per second so I can easily see each individual render?

Edit Ignore that last question (I'm still not sure which DBPro commands have been disabled). I've just inserted a wait 1000 between the two renders and I get a black screen with the borders for about a second followed briefly by the greenish image with the cubes. My interpretation of that is that the black screen is coming from line 130:



whereas the greenish image is coming from line the main render of camera 0 i.e. line 135



Out of curiosity I printed out the value of cam - this turned out to be 285371458 (the 5's might have been 6's - I couldn't tell ). Should the cam id be that high? I expected it to be a number in the range 1-31 or have I misunderstood again?


Powered by Free Banners
Van B
Moderator
16
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 6th Apr 2016 14:01
Love this plugin, I've only just started experimenting with it but am looking forward to getting my hands dirty with some new functionality in DBPro.
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 6th Apr 2016 14:11 Edited at: 6th Apr 2016 14:13
Green Gandalf wrote: "If I have understood things correctly, the main camera id is just 0 so the bit shift operation doesn't actually do anything so commenting out the bit shift part should have no effect which is what happens."

1 << 0 = 1 (ie. the one isn't bitshifted at all and remains as a one).
The reason for putting that there was just to demonstrate how to easily work with cameras with other id's, you could indeed just call it as DX11 SET SYNC MASK 1 in this particular case.
However, what I meant was that you should try calling it as DX11 SET SYNC MASK 0, like you did anyway with the 0 << DX11 GET CAMERA ID(mainCam).

Green Gandalf wrote: "I just get a black screen which I guess is because the shift operation stops camera 0 from being rendered and is what I would naively expect. I guess that means the problem is somewhere else. Or have I misunderstood?"

That would mean that the secondary camera ("camera 1") doesn't draw directly to the back buffer (which it isn't supposed to do either, so that isn't the problem then indeed).

Green Gandalf wrote: "I get a black screen with the borders for about a second followed briefly by the greenish image with the cubes"

That seems to indicate the afforementioned thing being at fault still though (the secondary camera somehow draws to the screen). Try putting another WAIT after the DX11 SYNC call to see if you indeed get both renders or if it's just happening to render one or the other, every so often picking the green one for the main camera render.

Green Gandalf wrote: "Out of curiosity I printed out the value of cam - this turned out to be 285371458 (the 5's might have been 6's - I couldn't tell). Should the cam id be that high? I expected it to be a number in the range 1-31 or have I misunderstood again?"

That isn't a camera id but rather a pointer to the camera object - simply put it's the memory address of the camera data. That's why DX11 GET CAMERA ID() is used to retrieve a ID in the 0..31 range that can be used in bitmasks.
The reason for using pointers directly instead of the ID system used by DBPro is to remove some overhead. Assume you have 10000 objects; each time you access object "42" this has to be looked up to find the actual object data, which adds up with multiple function calls like OBJECT POSITION X, OBJECT POSITION Y, and so on. Granted a hash map lookup isn't all that slow but it still seems unnecessary. Such an numeric ID system may be implemented in the future based on public opinion though; I've heard some people prefer it.

Van B wrote: "Love this plugin, I've only just started experimenting with it but am looking forward to getting my hands dirty with some new functionality in DBPro."

Thanks!
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 6th Apr 2016 17:19
Rudolpho

I've done a bit more experimenting and have found a way of removing the flicker. I changed this line



to this



and the demo runs smoothly without flicker, i.e. all I see is the group of cubes rotating against a pale green background.

I tried that because 1600x900 is the desktop resolution on this machine and wondered why the fullscreen option had been set to false. This solution worked on all the DBPro screen options I tested (those set in the Project Properties panel). Perhaps the source of the problem lies there somewhere?

Quote: "Try putting another WAIT after the DX11 SYNC call to see if you indeed get both renders "


That is in fact what I did - in which case I get the black render for one second followed by the green render for one second, consistently alternating between the two. This was only stopped when I made the change to the fullscreen setting in the DX11 INIT call as noted above.

Thanks for the explanation about the camera IDs. Perhaps there needs to be a brief note in the Help file somewhere?


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 6th Apr 2016 20:07
Hm, that's curious.
Indeed it was supposed to run in a window with less resolution than full screen. I just tried scaling it up to my screen resolution and keeping it windowed however and I get no such flickering. It could possibly depend on your graphics card, though I cannot see why it should behave like that at all unless something goes seriously wrong. Does it still happen if you run it in windowed mode but at some smaller size? Maybe 1366x768 (in case keeping the aspect ratio is relevant to reproduce the issue)?

Quote: "Perhaps there needs to be a brief note in the Help file somewhere?"

It probably does. At some point I intend to write some type of "getting started" tutorial rather than just the per-command documentation there is at this point.
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 6th Apr 2016 22:02 Edited at: 6th Apr 2016 22:10
Quote: "Does it still happen if you run it in windowed mode but at some smaller size?"


Yes. I've tried several combinations of DBPro Project panel settings, Window resolutions and values for SCREEN_WIDTH and SCREEN_HEIGHT and the only thing that stops the flickering is changing that fullscreen option from false to true - and then I lose the heading. Another oddity: when I run a smaller window using false I see two windows as in the attached image, one covering the other (both are movable separately. One is flickering, the other is always black. I've copied them separately from the screen and pasted them one above the other. I was running the program using Windowed mode with 640x480 set in both the Project panel and the program code.

Edit An afterthought: have you tried artificially reducing the fps as I did? Do you still see just one image or two? Has anyone else looked into this?


Powered by Free Banners

Attachments

Login to view attachments
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 7th Apr 2016 00:23
Hm I see...
The other window is DBPro's render window; it appears unless you use either HIDE WINDOW or set the display property to "hidden" as I tend to do. As you can see it can get quite annoying just sitting around there, and the fact that closing it closes the whole program isn't a favourite feature either

Quote: "An afterthought: have you tried artificially reducing the fps as I did? Do you still see just one image or two?"

Yes I did and no, it just renders the "main" image as it should for me, that's what's making it all the more mystifying.
More reports from others with different setups may prove useful in finding the cause so if anybody else is able to check whether they can reproduce this that would be most welcome.
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 7th Apr 2016 17:52
Quote: " it appears unless you use either HIDE WINDOW or set the display property to "hidden""


Yes, either of those fixed that particular issue.

The flickering issue remains. Lets hope others jump in with their results.


Powered by Free Banners
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 7th Apr 2016 22:13
Rudolpho

I've wrapped up the version of the screen quad demo that gives me the flickering including the exe in the attached zip file. Could you test both just in case there's something silly in my changes to the code or in my DBPro installation? If they seem fine to you then it sounds like my hardware is at fault.


Powered by Free Banners

Attachments

Login to view attachments
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 7th Apr 2016 23:52
Your program runs without any flickering for me.
However, I seem to recall having to make a change to my rendering routine when drawing shadow maps a while back. Simply put I was making a function call that swaps the back and front buffer when rendering my shadow maps as well; since these are only ever drawn to off-screen targets no swapping was necessary. All this accomplished was making some debugging logs look more neat and tidy (I assume the runtime realized there was nothing to be done since the particular render target wasn't in the swap chain). However since you mentioned being on Windows 10 (if I recall correctly?) this may work differently there and it is quite possible that that buffer swap occurs for *all* camera render passes in the latest dll release. If so that may explain the issues you're experiencing.
I will look into this theory and get back with my findings tomorrow.
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 8th Apr 2016 11:53
@Green Gandalf:
Indeed that was still happening in the latest version of the DBPro dll. Give the attached rebuild a try; hopefully this should solve it.

Attachments

Login to view attachments
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 8th Apr 2016 16:41
Quote: "Give the attached rebuild a try; hopefully this should solve it."


It does! Thanks!

But some of the other demos now give "Could not find function" runtime errors.


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 8th Apr 2016 18:15
That's good to hear

Green Gandalf wrote: "But some of the other demos now give "Could not find function" runtime errors."

And that is slightly less good news
I have moved the project over from Visual Studio 2010 to 2013 since the last "official" DLL build. It turns out that this changed the exports a bit, I just hadn't noticed it in the normal executable builds. I will try to figure out what causes this and what to do about it. In the worst case scenario I guess I'll have to alter all the string table entries to correspond to the new versions by hand, but hopefully it's just some compiler setting that can be changed.
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 8th Apr 2016 21:35
Thanks for confirming.

I always dread upgrading anything - something always breaks.

Hope you find a simple fix.


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 9th Apr 2016 12:12
Quote: "I always dread upgrading anything - something always breaks."

Haha indeed...

Well, I think I got it sorted; give the attached plugin a try


Incidentally I also noticed that the pyramid in the displacement mapping example is quite severely incorrectly distorted at the backside, as opposed to just at the connected edges. I may have to do something about that in the future; it is probably due to the normal direction being wrongly calculated in the shader.

Attachments

Login to view attachments
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 9th Apr 2016 14:51
Quote: "Well, I think I got it sorted; give the attached plugin a try "


Everything works now - except for one small thing. The screen quad demo runs but sometimes loses focus when run from the main DBPro editor. Haven't yet isolated the conditions which cause this.

But no error messages - and no irritating flashing, so you're almost there.


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 9th Apr 2016 15:33
Great!

Green Gandalf wrote: "The screen quad demo runs but sometimes loses focus when run from the main DBPro editor. Haven't yet isolated the conditions which cause this."

That is caused by the HIDE WINDOW call.
This will activate the DBPro window, which is then hidden. This process isn't instant, so if you add a SLEEP 50 or around there after the HIDE WINDOW call, it will not steal focus away from the DX11 window. A better solution would probably be to make the DBPro window hidden by default (by using the "hidden" display type as previously mentioned) or by programatically setting focus to the DX11 window once setup is complete. The function DX11 GET RENDER WINDOW HANDLE, as requested by Chris Tate, is present and available in the version attached to my previous post and can be used to facilitate this by calling SetActiveWindow from user32.dll.
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 9th Apr 2016 16:22
Quote: " This process isn't instant, so if you add a SLEEP 50 or around there after the HIDE WINDOW call, it will not steal focus away from the DX11 window. "


That fixed it.

Quote: "or by programatically setting focus to the DX11 window once setup is complete"


Would it be better to include it as part of the DX11 initialisation command?


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 10th Apr 2016 09:20
Green Gandalf wrote: "Would it be better to include it as part of the DX11 initialisation command?"

It already does, but as said there is some delay between when the windows messages for activation are sent and when they are received such that the effect of HIDE WINDOW occurs after the DX11 INIT window manipulation.
I'm not quite sure about the particulars but my window spawns a separate thread for handling its messages; presumably this takes some time during which any incoming messages to the window will queue up. You'd still think that they should come in in the right order though, so this is probably something that could be fixed. I will take a look at it once I manage to get my new nemesis, the arcball, to work as intended. Truth be told I think around 90% of the render window code is about two years old at this point and could probably do with a review anyway.
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 10th Apr 2016 12:44
Hopefully it'll be a minor fix. With luck I'll find time to do some real experimenting with your code later this week.


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 11th Apr 2016 11:37
Green Gandalf wrote: "With luck I'll find time to do some real experimenting with your code later this week."

I'm looking forward to see what you can accomplish with it!
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 12th Apr 2016 13:39
Another glitch - caused by your version of MD5.DLL. I was having difficulty compiling Evolved's demos because of his extensive use of included files. They just wouldn't compile till I reinstated the original DBPro version of MD5.DLL. Here's the thread

https://forum.thegamecreators.com/thread/216893?


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 12th Apr 2016 17:29
Hm I see... I haven't been able to reproduce your issue; is it possible you're using an old version of my MD5.dll mod? It used to have problems with certain include directives earlier but those have since been solved.
Otherwise I posted a slightly more elaborate reply to your thread.
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 12th Apr 2016 23:42
The only way I can get the Advanced Lighting demos to work is to change them so the files are included on the Solution panel and not in code and, at the same time, use the original DBPro version of MD5.DLL. In other words they won't work when unzipped from Evolved's zip file. I'm still rather baffled because the old versions of AL do compile without the changes to the code (but still need the TGC versio of MD5.DLL. I'll send you the zip file I downloaded yesterday from Evolved's site.


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 13th Apr 2016 18:42
Green Gandalf wrote: "I'll send you the zip file"

I don't know if you've gotten around to doing that yet, but if so I haven't received it.

I think I have been able to figure out the issue though (basically related to the relative path in the #include directive; you can try changing it to omit the "Include/" folder and just being #include "Advanced Lighting.dba"); give the attached MD5.dll a try

Attachments

Login to view attachments
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 14th Apr 2016 11:30
Quote: "I don't know if you've gotten around to doing that yet, but if so I haven't received it."


Sorry about that. My mailer refused to send it because it was too big - and I didn't have time to prune out the stuff that wasn't needed. I did notice that one of my comments on the other thread was wrong - I'd forgotten that when I commented out all the #include statements that would mean that the other demos using the same include files would need to have the same changes made. Anyway the upshot of that is that I still need the DBPro version of MD5.DLL to compile and run.

I'll try your new version now on a clean copy of Evolved's AL demo - to avoid any silly mistakes that I've made .


Powered by Free Banners
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 14th Apr 2016 11:46
Quote: "I'll try your new version now on a clean copy of Evolved's AL demo - to avoid any silly mistakes that I've made"


Yes!! That works - on both Evolved's original demo using #include and the alternative using the Solution panel.

Thanks for taking the time to fix this - I realise how hard it can be to fix a bug that you can't reproduce yourself.


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 15th Apr 2016 10:02
That's great to hear

Green Gandalf wrote: "Thanks for taking the time to fix this - I realise how hard it can be to fix a bug that you can't reproduce yourself."

Luckily it was in a pretty obvious location since my MD5.dll resolves includes itself in order to precompile all source files, so it wasn't that hard to trace. It would also have been reproducible if the project's CWD lacked a backslash at the end of the path (which made it look for the non-existant "Advanced LightingInlude\whatever.dba" instead of "Advanced Lighting\Include\whatever.dba"); maybe it's a Windows 7 vs. 10 thing or I just got lucky that mine had that trailing backslash.
Green Gandalf
VIP Member
14
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 15th Apr 2016 16:04
Those / or \ issues can be irritating. A bit like the problem of different line endings in text files.


Powered by Free Banners
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 13th Jun 2016 16:42 Edited at: 13th Jun 2016 16:54
While I don't like to tease unfinished things, I believe I have little choice unless the thread will get locked because of 60 days of inactivity.

Steady progress has been made over the last months, however there are some annoying issues (mainly related to achieving shadow mapping that looks decent in any given situation) that are taking way more effort trying to resolve than I'd care to admit. I will keep looking into it for a while, but if I can't seem to solve it in a reasonable amount of time I figure I'll go ahead and release version 0.5 and put those issues on the backlog for now; it is quite annoying to be held back by such a relatively "minor" issue for so long. Apart from that I have also had some things going on in my life that have limited the amount of time I could spend on this project to some degree, so it isn't me all being lost in the shadows</bad-pun>.

To give this post some contents worth reading I'd figured I would put a short summarisation of the new features coming in version 0.5:
Quote: "
The lighting system
This is obviously the main part of version 0.5. The engine now comes with a default lighting system that supports an
arbitrary number of directional, spot and point lights and optionally normal and specular mapping.
Each light source can also cast shadows (though they don't need to) and each and every object instance can be set
up whether it should cast shadows or not. Whether an object receives lighting depends on its shaders; there will be a
bunch of default shader techniques included but the lighting system can easily be included to work with any custom
(user-defined) shaders as well.
Shadow mapping is supported for each light type and two different shadowing algorithms are available to use for each
individual light source;
○ The default algorithm uses depth buffers as "shadow maps". This allows them to be quite efficient. A 3x3 PCF software
filter is utilized to give these shadows smoother edges, at a relatively small performance penalty. Since depth buffers
are used to store the shadow maps, not much post-processing can be done for these shadows.
○ Optionally the more costly exponential variance shadow mapping algorithm can be used.
This allows post-processing for better looking shadows, such as variable size blur filters, mip mapping, anisotropic filtering
and multi-sampled anti-aliasing. The main penalty over the default shadows is that EVSM uses about 7 times as much memory.
On the other hand there are some situations where one can get away with using a lower resolution shadow map than would
be needed to achieve comparable shadows with the default algorithm.

Material system
Each object can now have a set of material properties attached and available to shaders.
The (default implementation of the) lighting system uses some of these such as diffuse colour, specular intensity, etc., but
you can also add your own properties, or replace some of the default ones as long as you're using your own shaders.

Support for external input devices
Things like gamepads, joysticks, etc. can now be accessed directly from the Ziggurat engine.
This functionality supports both XInput and DirectInput devices with the same, easy to use function set, meaning full
support for XBox controllers (including shoulder buttons and force feedback) as well as other devices not available through
XInput.

Default shader library
A set of various "standard" shader techniques will be available for use.
For a start this will be a set of different vertex and pixel shaders that provide different complexity versions of the lighting system,
ie. the default shader applied to all objects unless otherwise stated will only assume it has a diffuse texture, while other shader
techniques are available for when you have normal and specular maps.
More shader techniques are intended to be added to the "library" over time, such as a standard distance-based tessellation
implementation for round-edged meshes and so on.

Shader precompilation
Shaders can now be loaded in (compiled) from a HLSL source file and then saved in a bytecode format.
This allows significantly faster loading of complicated shaders that may take time to compile for each run of your program.

Shader inclusion and macros
Pre-written HLSL code can now be provided to your shaders through inclusion, allowing for code reusability.
You can also provide HLSL code from DBPro as a string, and define macros from DBPro.

Multi-sampled render targets
Hardware MSAA filtering can now be used with render targets.

Image resampling
Images can now be resampled to change their formats, resize them or combine colour channels from different images (ie. "take the red
channel from this image and put it in the red channel here, then take the red channel from this other image and put it into
the green channel of my new image").

Custom draw order
Draw order priorities can now optionally be set for objects and limbs.
This can be useful to ensure your skybox is always drawn first, and everything else on top of it, or ensuring that some 3D UI components
are always drawn on top of everything else, regardless of their depth in the scene.

Custom graphics card selection
You can now obtain a list of the available graphics cards and select which one to use prior to initiation.
Furthermore, if no custom graphics card selection is made, the default behaviour is now to try to identify and use the "most powerful" one
instead of using the system default card.
"


Apart from this, I also plan to provide a rebuilt version of the DBPCompiler.exe that will increase the maximum dll function count and perform the necessary precompilation work for line number reporting on errors, if any function calls to the DX11 Plugin is found in the source being compiled. This will then remove the need for the hackish MD5 patch that has provided this functionality in the past.
There may also be a special mystery function, but more on that later...

Login to post a reply

Server time is: 2019-06-15 22:30:36
Your offset time is: 2019-06-15 22:30:36