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
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 20th Jun 2014 00:52 Edited at: 20th Jun 2014 00:54
Sorry for the delay with replying. I didn't want to hit that 50:th "hot" post without having something new to show off but it seems I don't need to worry about that anymore now (thanks Sam! ).

I'll admit I haven't been putting very much time into this since my last update, but here's some eye candy showing a geometry shader in action:

While not a particularly pretty demo, it shows the rendering of a single-mesh 1024x1024 terrain as well as 1024 patches of 2000 crossed planes-style grass objects each (which translates into ~4.1 million quads or ~8.2 million triangles, plus another 2 million for the terrain) running at a solid 60 frames per second. (As a matter of fact it runs at somewhere between 75 and 180 FPS on my machine when the framerate isn't capped by Fraps). As for the evident lagging in the video, this too is caused by the video capturing program.
Apart from the built-in frustum culling that operates on the 1024 grass patches, there is no optimization whatsoever in this scene meaning it should be perfectly possible to render quite dense, lush foliage in a "real deal" scene.
As mentioned above, all grass objects are created from 1024 "grass patch" objects, each consisting of 2000 vertices. The geometry shader then expands each such vertex into 8 vertices (two crossed quads) to create the individual grass tufts on the GPU. It also applies a really cheap per-vertex animation on the generated vertices. An interresting thing to try would be to have fewer, smaller unique grass patch objects and instead use hardware instancing on these; that would likely allow cranking out a few extra frames per second.


@Chris: Glad to hear it finally worked. Good luck with your projects; I'm well aware how much time they can eat away.

Quote: "When Dx9 finally dies for good though, your awesome plugin will save us all, Rudolpho "

Haha, well... by then DX12 is most likely here, if not 13
And to be honest I think most people are starting to leave DBP and its likes for complete game engines with visual editors such as Unity as they seem to be becoming more and more available by each they. Now I'll admit Unity is quite amazing, but it seriously makes people think that "you're... a games programmer?? What's that, you just drop some models and asset-store scripts into Unity and it just works! :o" which is getting on my nerves...


"Why do programmers get Halloween and Christmas mixed up?"
MrValentine
AGK Backer
8
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 20th Jun 2014 01:15
Private Video...

Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 20th Jun 2014 01:22
Quote: "Private Video..."

D'oh... well should be fixed now


"Why do programmers get Halloween and Christmas mixed up?"
MrValentine
AGK Backer
8
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 20th Jun 2014 01:46
I think Rudolpho should apply for working on DBPro: Elite... It sorely needs DX11, ignore the multi skin layering stuff, just the shear speed improvements alone would justify the shift...

Just saying...



Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 20th Jun 2014 19:13 Edited at: 20th Jun 2014 19:16
I think Microsoft are moving way too fast with Direct X 12, although they are probably eager to promote the next operating system and games console. They must repair the damage of their reputation caused by a number of flagship product let downs.

So far Direct X 11 has not brought much success to the PC gaming market with a few exceptions, such as Farcry 3. By the time us developers get a chance of mastering current technology, we have to start over learning the new stuff. Microsoft need to slow down and give us some time to produce good games.

MrValentine
AGK Backer
8
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 20th Jun 2014 20:22
In case I got this wrong, I might have this wrong, ok that is that out of the way...

DX11 has a feature level system, 9.3 I think is DX9.0c support...

Look into DX11 Feature levels...

Mind you DX11 is DX10 Plus a little more, my guess is the feature levels mainly...

Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 20th Jun 2014 22:22
Indeed, many developers are still creating DX9 games, and most DX11 games provide backwards compatibility using the feature level system you highlighted.

Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 21st Jun 2014 01:33
Quote: "I think Rudolpho should apply for working on DBPro: Elite..."

Haha, well... I do need to get a job...

Quote: "I think Microsoft are moving way too fast with Direct X 12, although they are probably eager to promote the next operating system and games console."

I agree, however the main selling point seems to be "platform independence" (of course it will probably still only run on Microsoft devices, but you can add their fancy Windows Phones along with the XBoxes to the list I guess). We'll see what it contains more specificly soon enough I guess. But I completely agree, there haven't been much DX11-exclusive software made (most likely due to developers wanting the biggest possible user base for their program, thus opting to support older hardware) and it isn't right that I should quite literally have to rely on third party software for Windows 8 to behave somewhat desktop-like.

Quote: "Look into DX11 Feature levels..."

Yes, those exists and they are quite nice. They do sound better on the paper than they are in the real world however; in order to run DX11 in "backwards compatibility mode" the computer that runs it must still have the DirectX 11 runtime installed. Although DX9 is "supported" the DX11 runtime can only be installed on Windows Vista SP2 and above (legitimately at least, there are some hacks floating around to get DX11 on Windows XP I've heard). Since most any Vista and above computer will most likely at least have a DX10-capable graphics card the point of the DX9 feature level is kind of mote.


"Why do programmers get Halloween and Christmas mixed up?"
Kuper
11
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 21st Jun 2014 03:14
well done Rudolpho!

Quote: "And to be honest I think most people are starting to leave DBP and its likes for complete game engines with visual editors such as Unity as they seem to be becoming more and more available by each they."

Maybe they have no choice after some years without updates?
Few days ago I was watching for lipsync program for face animation.Find DarkVoices but discovered that is made in 2006 so about 8 years ago....
Still nice work and waiting for next demo !
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 3rd Jul 2014 19:12
Thanks Kuper

Not much to show yet I'm afraid; I've been battling with hardware tessellation since my last post and thought I had it a few times - unfortunately it seems this functionality is really hard to get to work in a feasible way (ie. without unpleasant visual artifacts when tessellation factors change or disconnected vertices) and that appears to be the reason why almost no current games opt to use it. That said, both the hull and domain shader stages are now accessible from the engine / plugin and are in fact working; it's just my pride that tells me I have to write a proper shader using it before showing it off


"Why do programmers get Halloween and Christmas mixed up?"
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 12th Jul 2014 19:41 Edited at: 12th Jul 2014 19:59
Hardware tessellation supported

Here's another video, this time showcasing dynamic hardware tessellation based on distance from the rendering camera as a means to increase the detail of meshes through offsetting these added vertices in accordance with a displacement / height / bump map.

As usual Fraps decided to cause lag spikes every now and then; these do not occur when the program is run without video capturing. Also I get a bit disoriented when these lags cause the camera to face a completely different direction every once in a while. Also Youtube again decided that my 10Gb source video was overly fancy and applied that horrendously ugly jpeg compression this time as well...
It should also be noted that without video capturing running in the background, the demonstration application runs at a solid 1400 - 1700 FPS on my machine (when not using wireframe rendering which slows down with the amounts of triangles used here). The video also leads on that using the GUI sliders cause lags; this does not happen at all and is merely Fraps getting upset because changing the sliders cause most pixels on the screen to change between two consecutive frames I guess.

A few things about tessellation-driven displacement mapping
Unfortunately getting proper displacement mapping up and running isn't as simple as just adding some lines of HLSL for it. Most of the time it will require artist intervention; the two main things to be aware of is that you cannot have shared vertex positions which define different normals (such as on the straight corners of a cube); this will cause the vertices to be displaced in different directions and thus they will no longer appear connected, causing gaps in the mesh (assuming that you do displace along the normal, otherwise this shouldn't be a problem). Zink, Pettineo & Hoxley (2011) suggest that this kind of problem is normally solved by having the artist create all corners as rounded by inserting additional vertices. These can be extremely close to each other in position but they should not overlap, which will cause near unnoticeable smoothing of the normals between the two vertices.
The other thing to be aware of is that it may be necessary to provide secondary texture coordinates for the displacement map, or the displacement map should be handcrafted in such a way that any vertices having the same position but different texture coordinates should be offset by the same amount lest the afforementioned gaps will appear again.
Since I'm not a graphical artist my demo program shown in the video above "solves" these problems in the naïve way of programmatically averaging disjoint normals and only sampling the displacement map UV's from a "dominant" vertex at every location (which is arbitrarily defined as the first one found at that position in a pre-processing step). This works but is of course not ideal and may deform the meshes in undesired ways, although this may not be particularly noticeable. There are other ways around this, but they get very involved with lots of heavy math and essentially seem to try to abstract away the concept of vertices and polygons and instead work with mathematically defined curves.
With more complex meshes, care must also be taken so that polygons won't accidentally intersect each other when they are displaced (this can be ensured by an artist manually creating / tweaking the displacement maps; mine were just auto-generated by CrazyBump or I used bump maps that I could find along with the textures).
Yet another thing to be aware of is that the fixed-function tessellator stage of the shader pipeline can only subdivide each input face up to 32 times along each axis. This means that you will normally have to provide semi-high resolution meshes to begin with in order to achieve the desired level of detail (for example the floor plane in the video above is made up of 48x48 tiles which each tessellates into 32x32 sub-tiles when the camera is close enough).
As can be seen mainly on the pillars (which are just 8x8x8-segmented cylinders; by the way all pillars are instances so it is perfectly possible to tessellate instances differently based on how far away from the camera they are, or whatever other way of determining this you may have), the added vertices will slide towards new positions as they are inserted to the mesh. This can look quite annoying at times, but that's just the way it works unfortunately. It is less evident the higher the vertex resolution used. It is also possible to use the integer or pow2 partitioning methods; these will pop in new vertices full on in their final positions without trying to interpolate them in like the used (fractional) approach does. This may be preferable in certain situations; the visual effect will be the same as when swapping LOD:s without any kind of smoothing transition.
One application where tessellation may prove very valuable is in rendering things like terrains in a single draw call; you can send a 128x128 quad in, tessellate it up to 4096x4096 and have dynamic levels of detail automatically in-between. Since the hull shader (first part of the tessellation stages) can cull faces before they get tessellated this has the potential of being very efficient. For that reason it is also commonly used for animated water planes where the geometry is dynamically displaced in wave-like patterns.
Lastly, tessellation is the first (and probably most major) functionality of the DX11 Plugin that can not be used in the DX10 compatibility mode.


"Why do programmers get Halloween and Christmas mixed up?"
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 13th Jul 2014 01:52
It looks amazing!

thenerd
10
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 13th Jul 2014 16:28
Amazing job!

Quote: "One application where tessellation may prove very valuable is in rendering things like terrains in a single draw call; you can send a 128x128 quad in, tessellate it up to 4096x4096 and have dynamic levels of detail automatically in-between. Since the hull shader (first part of the tessellation stages) can cull faces before they get tessellated this has the potential of being very efficient. For that reason it is also commonly used for animated water planes where the geometry is dynamically displaced in wave-like patterns.
"


That's actually what excited me most about the video. I noticed that as you move the camera away, the LOD fades the vertex positions from the tessellated positions to the non-tessellated positions for a smooth transition. This type of lod is the best in my opinion, but I have never figured out how to displace the vertices like that. Any tips regarding this? Was that an effect built into DX11 or did you hardcode it into a shader?


Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 13th Jul 2014 23:22
There are many applications for such tecniques; some not quite what most people would think of.

Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 13th Jul 2014 23:49 Edited at: 13th Jul 2014 23:54
Thanks guys

Quote: "I noticed that as you move the camera away, the LOD fades the vertex positions from the tessellated positions to the non-tessellated positions for a smooth transition. This type of lod is the best in my opinion, but I have never figured out how to displace the vertices like that. Any tips regarding this? Was that an effect built into DX11 or did you hardcode it into a shader?"

It is somewhat of a mixture of both. You have to send tessellation factors that determine how many times the edges and insides of triangles (or quads, if you use that like you might for a heightfield-type mesh) should be subdivided by the fixed function tessellator; I set these based on how far away the edges are from the camera. Now the tessellator stage can be told to partition the added edges in one of four ways; the simplest one is integer where as many edges as are defined by the input tessellation factors from the patch-constant function are added and evenly distributed across the surface of the original face. The second is a power of two-type partitioning which will give you 2, 4, 8, 16... subdivisions. This is good for creating dynamic LODs since it maps directly to the resolution changes in texture mip maps. Both of these methods just insert the new edges in their final positions straight on and will thus cause visual "popping" when the vertex resolution changes from one frame to the next.
To get around this the other two partitioning methods accept floating point values as tessellation factors. Of course we cannot add 2½ edges so what it does is add new edges at the position of the closest edge present in the lower LOD and then interpolate these positions from that starting position and to its final "actual" position (where it would've been with integer partitioning) as the fractional part of the tessellation factor goes from 0 to 0.9999...
It should be noted that all subdivided faces and their vertices are available to the domain shader stage after the tessellator stage so that you can offset them as you please from there (much like how I offset them along the vertex normals in the previously posted video).

One thing to be aware of if you're trying to implement the interpolation technique described above is that you will have to add 2 edges for each new increase in detail level to each end of your face (it wouldn't make sense to just add one at a time). As for sliding them, a standard linear interpolation from the "previous" / outer edge's position and the target position with the fractional part of the tessellation factor (or LOD factor as I assume you're trying to accomplish this without actual hardware tessellation?) as the percentage factor.


Edit: forgot to say it but as you can see at ~6:21 - 6:25 (the cylinders) in the video this edge sliding causes quite noticeable visual artifacts if the objects don't have a high enough vertex resolution which probably won't be desirable most of the time (unless you're making a game where everything tessellated is made out of jelly that blows itself up in a bouncy fashion as it detects your presence)


"Why do programmers get Halloween and Christmas mixed up?"
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 16th Jul 2014 00:20
2D functionality has been extended
Much in line with what the_nerd requested back in April, the 2D functionality has now been extended to include animated sprites, the possibility to use custom pixel shaders to render sprites, functionality to manually set a sub-section of an image to a sprite (ie. "I want to use the part of this large image between pixels (256, 96) and (512, 608) as my sprite"). Convenience functions for mirroring and flipping sprites (which can be done using the afforementioned functionality) have also been added.
To move away from sprites, simple shapes (lines, boxes and circles) can now be drawn immediately on a per-frame basis without the need to create sprites for them. You can also draw text (optionally centered) and images (with a custom size and opacity) in this manner, as well as "paste sprites" to the screen. When pasting sprites, their transform (position, size and rotation) can be set for each pasting (apart from that they retain the attributes of the source sprite being pasted, such as custom shaders) and thus allow the same sprite to be drawn several times without the need to create duplicate sprites for it.
All such drawing operations currently end up on top of all 3D and "normally" drawn sprites, in the order they are defined in your code.

As for sprite shaders, you can set a custom constant buffer for each individual sprite as a means to exchange custom per-sprite data to your pixel shader program (of course several sprites may also use the same constant buffer, or none if you don't need additional information). It is also possible to set multiple images for each sprite now, should you need it in your pixel shaders.


Here's a video showing some of the features mentioned above in action. It's really not much to look at but I thought I might as well (and I finally figured out a proper format for efficient uploading to Youtube, so that's good )



There have also been some other, minor updates, namely:
Up to 16 different textures per object / limb / sprite are now supported (as opposed to the previous 8 for objects / limbs and a single one for sprites).

You can also have up to 16 different sampler states per shader technique to match the above expanded texture count.

A "bug" where the screen resolution would be ignored if setting the fullscreen flag for DX INIT has been fixed; it will now run in whatever resolution you specify to the same function, provided that the target monitor / system support it.
(The previous behaviour where the current resolution of the monitor was used was actually intentional from back in my early days of messing around with DX11 with the reasoning that "why would you want to run full-screen with anything less than full resolution?", but this should of course be up to the programmer who uses the library to decide so it has been removed).



Here's a changelog of the latest updates:



"Why do programmers get Halloween and Christmas mixed up?"
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 16th Jul 2014 00:49
16 textures; music to my ears.

Sprites with multiple textures; brilliant. Handy for all sorts of games; you could have characters with seperate costumes or you could animate powerups on one texture, animate the character on another and blend them nicely with a sprite shader.

Sprites and drawings appear to reside on different render passes in Dark Basic. You have to use Draw To Front / Back or resort to sprite pasting to incorporate sprites, drawing and text with flexible layering; otherwise text gets overlapped by all sprites. Do your sprites work like this?

Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 16th Jul 2014 01:22
Glad you like it, yes, extra textures can always come in handy
It's a tradeoff because most objects won't need that many, but will still have to allocate memory for them and update all shader resource slots, but this maximum number of textures might be further tweaked in the future. While you can have up to 128 textures bound to the shader stages, each shader stage needs to have its own copy and they all count towards that maximum. Also, the maximum available amount of samplers at the same time are 16 so it made sense to set it to that. It is possible that 24 or 32 texture slots could be warranted for multi-textured terrains with lots of shadow, normal and detail maps however.

Quote: "Sprites and drawings appear to reside on different render passes in Dark Basic. You have to use Draw To Front / Back or resort to sprite pasting to incorporate sprites, drawing and text with flexible layering; otherwise text gets overlapped by all sprites. Do your sprites work like this?"

Yes, normal 3D geometry is rendered in its own pass, then sprites are rendered in another pass and now there's a third pass for all the simple / pasting 2D operations.
I forgot to mention it in my main post above, but as you can see in the changelog, there are also sprite layers now. These allow you to group sprites together into layers that can have their render priority changed and be hidden, which affects all contained sprites. Normal sprite priority values are still valid within each layer. In this way it is possible to ensure that all text is drawn on top of every other sprite for example, you can have a GUI layer, and so on. This will only work if you use the label resource however; the quick DX11 TEXT / DX11 CENTER TEXT functions will draw the text on top of everything else, except for if you draw any 2D shape or paste an image / sprite on top of that text after issuing the text drawing call.
I don't believe it would be very efficient to try to expose complete draw order control; there is automatic sorting based on shared states and resources implemented into the engine and overriding this would be inefficient. Also it would be hard to determine whether a certain sprite should be drawn before or after a 2D element (unless you give shared priority values to them all).
Still, as I can imagine most actual 2D drawing will mainly use sprites (remember, the Label system internally uses sprites), it is possible to perfectly control the drawing order of these using layers and priorities. The shape drawing will most likely only be used for simpler things, or if you really need to, you could set up a secondary camera that renders to an image, draw your 2D to that one, and associate its render target as a sprite for the main camera.


"Why do programmers get Halloween and Christmas mixed up?"
mr_d
DBPro Tool Maker
12
Years of Service
User Offline
Joined: 26th Mar 2007
Location: Somewhere In Australia
Posted: 16th Jul 2014 09:11
Excellent! But..ummm...where's the download for the latest version (DX11 Engine 2D updates as of 2014-07-15) you mentioned in your second last post?

Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 16th Jul 2014 13:19 Edited at: 16th Jul 2014 17:57
Is this going to be a free plugin, or do you plan to sell it commercially? I hate asking such questions, and hate answering them when I get asked; but it needs to be asked.

I would strive to make it purchasable because quality comes at a price and you need to eat; however some guys out there may disagree and there are exceptions where people create free software which ends up being popular, leading to funding from other sources.

PS:
Quote: " "But yeah, I'm the guy who tried to make a MORPG

Really? Wow, do you have any links to this project; I'd like to see what you came up with. What an achievement."


Just copied my comment from my thread, I wanted to see your MMORPG attempt. Why did you stop making it?

thenerd
10
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 16th Jul 2014 18:51
Very excited about these new 2d features


Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 16th Jul 2014 23:14 Edited at: 16th Jul 2014 23:17
Quote: "But..ummm...where's the download for the latest version (DX11 Engine 2D updates as of 2014-07-15) you mentioned in your second last post?"

Ah yes, maybe I should've made that clearer. There is no officially released demo version containing these functions yet (I would have to do some more work before then such as writing another 100+ help documents). I just thought I would make some more posts as to the current features to show what I'm currently working on and such, so that's why the last few "updates" posts have not been accompanied by any new downloads. Also I may have to rethink the DBP plugin distribution; I find that I'm getting ever closer to the seemingly arbitrary limit of 999 string table entries that are read by the DBP compiler and that before this is done that number might be exceeded in which case I would have to split the library into several smaller dll's.

Quote: "Is this going to be a free plugin, or do you plan to sell it commercially?"

That is indeed a hard question to answer at this point in time.
Ideally I would of course like to be able to earn a few nickels off of my work; if you consider the time I've put into this I would likely have earned at least ~€ 8000 (or ~12 000 USD) if I had spent that time working for minimum wage instead, so if I could at least gain 10 or 20% of that from it that would be nice. (Of course this isn't a completely applicable reasoning since it isn't like I'm making an active choice to work on this instead of getting a job). Still so it is also a matter of how big a target audience it has; I'd imagine it wouldn't reach many people and then that number gets greatly cut down as lots of people probably wouldn't be interested if there was a cost involved. I did actually send an enquiry to TGC last week to see whether they might be interested in distributing this product once it gets finished, but have yet to receive a reply so we'll see how that goes I guess.
Another possibility is to make the engine available to other languages, but since it is essentially based around being similar to DarkBASIC in functionality and concepts that may feel weird to users from other backgrounds. Also there are usually quite big open source game engines available for the bigger languages out there so it would be quite hard to gain any interest I believe.
In the end it comes down to the need for money to live and the desire for people to use and appreciate my work. Hopefully the two goals won't be mutually exclusive, but it is too early to say with certainty yet.


Quote: "Just copied my comment from my thread, I wanted to see your MMORPG attempt. Why did you stop making it?"

I replied to your other thread, but I'll reiterate that I didn't directly "stop" making it. As a matter of fact I first started development on my DX11 engine, which this plugin is a DBPro wrapper for, as a means of pulling that project off
The reason to make this as a DB plugin is highly nostalgic, it feels like I should give something back to the company and community that first got me interested in - and started with programming now that I am able to do so


Quote: "Very excited about these new 2d features"

I'm glad to hear it, thank you


"Why do programmers get Halloween and Christmas mixed up?"
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 17th Jul 2014 16:40
I had a look at a few of the game videos; it looks like a lot of work went into it; lots of scenery and a really big terrain. I know what it feels like to be the solo programmer, you have to do absolutely everything from class definitions to texturing...

I could not notice how it worked, but the terrain has lots of different textures applied seamlessly.

Those 95% who jumped over to unity to get their school work done probably did not learn as much as you did, developing a difficult genre from the ground up. Oh well, you have DX11 now so soon you will be having the last laugh.

Quote: "the game was actually called Ageing Wrath, which kind of stuck with everyone who heard it because they liked to point out how wrong that was in favor of the spelling "aging", however it seems ageing is indeed the correct brittish english spelling."


That is ironic and without a doubt funny. It is like Metal Gear Solid, Revengeance Vs Metal Gear Solid Revengance. (I also always wondered what Metal Gear Solid actually means... A metal gear that happens to be solid, right... but then I looked it up and found it had to do with the main character)

JackDawson
7
Years of Service
User Offline
Joined: 12th Jul 2011
Location:
Posted: 20th Jul 2014 06:59
Amazing stuff. I love the instancing demo. With all the grass and trees. Great job. Really looking forward to more.
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 21st Jul 2014 19:38
Just a quick update to say that I've finally brought the documentation up to date. I will continue to rewrite / restructure my geometry shader and tessellation example code into workable, to-the-point commented DBPro demo projects. Depending on the weather I estimate the latest demo version (0.3.0.0) can be made available along with said examples by wednesday or at least by the end of this week.

Quote: "I could not notice how it worked, but the terrain has lots of different textures applied seamlessly."

It uses a texture atlas, a blending texture and a tile texture, which essentially lets you map sub-textures from the atlas to segments of the terrain in four layers which are blended between based on the blend map.

Quote: "Those 95% who jumped over to unity to get their school work done probably did not learn as much as you did, developing a difficult genre from the ground up. Oh well, you have DX11 now so soon you will be having the last laugh."

Unity / UDK were recommended by the school. In a way they may ironically be better off at a job interview since they potentially have more experience with a professional engine that may be used at that place. But we shall see about that last laugh yet...

Quote: "I also always wondered what Metal Gear Solid actually means"

Haha, I've been wondering about that too actually!


@JackDawson: thank you


"Why do programmers get Halloween and Christmas mixed up?"
JackDawson
7
Years of Service
User Offline
Joined: 12th Jul 2011
Location:
Posted: 22nd Jul 2014 15:15
Hey there Rudolpho,

On your youtube video, Hardware tessellation supported, is that source code anywhere accessible ?

Oh and you're welcome.
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 23rd Jul 2014 01:20
I'm currently working on rewriting those demos to make them a bit more to the point and add in comments describing the various steps. They will be included as example programs with full source when version 0.3 is released as an official demo dll for download.
I've already completed shaping up the geometry shader demo (the grass video, it has got some improved settings such as proper terrain texture blending and less dense, paler grass tufts at higher altitudes now) and will continue on with the tessellation demo tomorrow, assuming it won't be 30°C and beaming sun again (that makes it hard to stay inside in front of the computer all day).

So basically the tessellation source should be available any day now


"Why do programmers get Halloween and Christmas mixed up?"
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 25th Jul 2014 03:21 Edited at: 27th Jul 2014 20:01
Version 0.3 is released and can be downloaded from the opening post or here.

This version includes all the new features and fixes detailed in the posts since the release of version 0.2; to summarize the main new features are full support for the remaining render-pipeline shaders (meaning that the full vertex->hull->domain->geometry->pixel shader chain can be accessed), increased number of allowable textures on objects and limbs (16 as opposed to the previous 8) and lots of updates to the previously rather lacking 2D functionality set - the main new additions here are sprite shaders, direct drawing to the screen of shapes (rectangles, circles, lines) and text, image and sprite pasting functionality, sprite layers and the possibility to set multiple textures (up to 16) per sprite for use with any custom multi-texturing shaders.

Two new examples with full, well documented DBPro and HLSL source are also included:
○ Foliage demonstrates a new, slightly improved version of the program demonstrated in the geometry shader demo video posted a few weeks back. Demonstrates the creation of a texture blended terrain mesh and then the positioning of about a million animated grass tuft objects on that through the use of geometry shaders and point list buffers.

○ Dynamic Displacement Mapping correponds to the program demonstrated in my hardware tessellation video.
As an added bonus there is a DBPro-powered GUI system included that could be built further upon or ported to standard DBPro rendering. This demonstrates some of the new 2D functionality, albeit not very much. The 2D functions should be relatively self-explanatory though so there probably isn't much need for an explicit example program for those.

Of course there are also new help files included for all new / changed functions.



As always, please let me know if you have any feedback, find any issues, missing functionality, or have other suggestions
I'm also contemplating rebranding the project to "Ziggurat" as a play on the DarkBASIC pyramid. The engine really needs a fancier name than "DX11 Engine" as it's been called for the last 9 months now

Edit: fixed the preposterous spelling mistakes in this post.


"Why do programmers get Halloween and Christmas mixed up?"
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 25th Jul 2014 13:06
Brilliant, I will be playing around with this in the weekend.

Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 28th Jul 2014 11:41
Do you have a list of DX11 compatible plugins available; like a series of third party plugins which one could use with your plugin as aposed to the ones which are not inherently compatible, or is this something you are planning to do at a later date?

Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 28th Jul 2014 17:32
I have thought of it but no, I have not put any such list together as of yet.

The key element is if the plugin uses the ID3D9Device pointer (or any other data that is dependent on it) from DBPro's Globstruct, it will not work. I do have a similar structure that provides the ID3D11Device and ID3D11DeviceContext pointers used by the engine that could be provided to any third party dll's interested, however there is of course no support for this from any such plugins at the current time.
With this information it shouldn't be hard for plugins that are essentially completely detached from the rendering to support my rendering engine instead; for example DarkPhysics, DarkDynamix*, etc. should theoretically work as long as they provide a means of reading mesh data from a different source than a "object id" that is dependent on a lookup from the DBPro globstruct.
Plugins that DO inherently depend on access to the DX9 interface will not work without semi-major tweaks on the part of the plugin author. This includes BlitzTerrain, EnhancedAnimations* and the D3D plugins.
Plugins that add completely new, non-DX-related features will work just as they are, such as most of Matrix1Utilities, various Windows GUI-plugins, DarkNET, etc. It is quite possible that DarkAI would work out-of-the-box as well since I believe it only uses abstract representations of entities and it is up to the DBPro programmer to update the visuals accordingly.


* I plan on wrapping up PhysX as an integral physics engine with the DX11 engine, as can be seen on the "planned features" list in the first post. This would then perform much the same functions as DarkPhysics / DarkDynamix, which are just PhysX wrapper libraries themselves.
As for EnhancedAnimations, the current animation system present in my plugin essentially provides the same functionality already.


"Why do programmers get Halloween and Christmas mixed up?"
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 28th Jul 2014 23:46 Edited at: 28th Jul 2014 23:47
That seems excellent; we can remain confident that functionality and gaming logic will not be limited, but rather increased by your plugin.

Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 30th Jul 2014 19:07
That would be the plan yes


"Why do programmers get Halloween and Christmas mixed up?"
Lucka
14
Years of Service
User Offline
Joined: 1st Oct 2004
Location:
Posted: 15th Aug 2014 16:29
Simply GREAT.

GJ Rudolpho, never give up!

Lucka - gawteam coder - www.gawgames.com
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 15th Aug 2014 23:21
I am back from my holiday now; still have not taken the time to test this out. I will put it in my diary and create some DX11 programs for fun (Now that I have a DX11 system)

Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 16th Aug 2014 22:27
Thanks Lucka and welcome back Chris, hope you had a nice vacation
Looking forward to see what you come up with (or what bugs you'll find )!

I had initially hoped to be able to release a new version featuring DirectCompute these days, but this has turned out to be more complicated to get right than I had expected. The functionality is present in the engine but I need to refactor lots of earlier functions since under certain conditions some arguments are illegal and the whole thing just needs to be better presented to the programmer. Features added due to the implementation of the DirectCompute facilities also permeates throughout lots of previously existing functionality (for example arbitrary data buffers share registers with texture resources on the shader side) so I think it will be better to get this right straight away and let it take some more time than to hurry out a bug laden release. Because of this the next released version will go directly to version number 0.4.0 rather than 0.3.5 as was stated previously.

So to summarize, GPGPU functionality is coming as soon as I can work out a feasible way to present all its quirks. The DX11 API itself does a pretty lousy job here where you basically get to combine various enumerations into a integer flag, but tonnes of them are mutually exclusive at the same time. Also many resources are only available in DX11, so the DX10-capable DirectCompute functionality is a bit limited.


"Why do programmers get Halloween and Christmas mixed up?"
GreenDixy
10
Years of Service
User Offline
Joined: 24th Jul 2008
Location: Toronto
Posted: 17th Aug 2014 08:41
@Rudolpho

I have been following this thread since it started, And hope it continues. It will be a great addon for the awesomeness of dbpro.

When you talk about "better presented to the programmer" Are you talking about the amount of code needed to make a program? Or the way it renders?

Keep up the great work, And take your time.

.:: Http://DeanWorks.Ca ::.
My software never has bugs. It just develops random features.
kingofmk98
7
Years of Service
User Offline
Joined: 30th Jul 2011
Location: Everywhere
Posted: 17th Aug 2014 11:02
Man, great work!
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 18th Aug 2014 12:27 Edited at: 18th Aug 2014 12:31
Thanks guys, it is nice to know that there is some interest in this

Quote: "When you talk about "better presented to the programmer" Are you talking about the amount of code needed to make a program? Or the way it renders?"

With that I meant that the API (which basically means the functions you have available from within DBPro) should be made more obvious and clear about what the functions are actually doing.
As it currently stands there is for example an interface, ID3D11Buffer, provided by DirectX. This interface is implemented by various buffer resource classes and it is basically a guarantee that the functions exposed by the interface should be available for the classes that implement it. However this isn't the case with for example the ByteAddressBuffer, which cannot be directly accessed by the CPU. Since the interface it is based on suggests it can this causes lots of confusion and it should really be better "presented" so that it becomes readily obvious that this limitation exists.
For this particular case it is still possible to read the (GPU-generated) contents of the byte address buffer back to the CPU through the use of an intermediary buffer where you essentially copy the contents of the source buffer to and the CPU can then read from that buffer instead. This will of course be slower than having direct access to the buffer so for most other buffer types I have included a flag to the functions that create them where the DBPro programmer can chose if he wants to have direct access to the buffer (which makes it faster to read / write from the CPU but slower to use by the GPU) or not (which instead makes it faster to access for the GPU and slower for the CPU thanks to the intermediary buffer). Depending on what you will use your buffer for, being able to set this flag will increase efficiency of your end-user programs. But since the particular byte address buffer only has one valid state (not directly CPU-accessible) it makes better sense to just handle this internally and abstract away the access method to the DBPro interface, so that it just appears as a buffer that can be read and written to by CPU and GPU alike.


"Why do programmers get Halloween and Christmas mixed up?"
James H
12
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 18th Aug 2014 19:43
Quote: "Thanks guys, it is nice to know that there is some interest in this"

I suspect theres a lot more interest than you realize, I havent tried it yet but at some point will, I think ppl just arent posting but reading to see how it progresses, 2.4k views for a start even with ppl rereading the thread - that seems a lot to me, besides x9 is difficult enough for some let alone skipping x10 and straight to x11(though x 10 would be a mine field if you ever downloaded the modders kit due to lack of examples/docs). Ive not posted till now but I was aware of it from when you first made the thread and will keep following this
Hockeykid
DBPro Tool Maker
11
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 18th Aug 2014 21:16
Quote: "Thanks guys, it is nice to know that there is some interest in this"

Quote: "I suspect theres a lot more interest than you realize"


Yes, while I personally haven't commented on this thread, I have been following closely. I tried it out awhile back and played around with the examples, it's quite cool to be able to use DX11 in DBPro. Once this plugin is completed, I'm sure I'll purchase it and use it for some future projects.


Sean

Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 19th Aug 2014 14:48 Edited at: 19th Aug 2014 14:51
I am writing my first DX11 programs this week. These snippets will have a need for feedback and critique at some point; where am I to post such snippets? Perhaps in the snippet section or in this thread?

Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 20th Aug 2014 01:36
Quote: "I suspect theres a lot more interest than you realize"

I suppose (and hope!) you may be right, but frankly the downwards trend around here with lesser and lesser activity and quite a few spiteful posts about the uselessness of DBPro and even Microsoft and DirectX themselves is a bit off-putting. I won't claim to not see the allure of open source and multiplatform deployment, and yes, DBPro haven't really gotten any official attention lately due to TGC chosing to focus on AppGameKit and FPSC Reloaded. I just hope this my contribution to the company and community that first got me into programming some 11 years ago won't be too late. So with this background information about the seemingly current state of things it is always nice to get some tangible evidence that there actually are people who would see it finished

Quote: "... besides x9 is difficult enough for some let alone skipping x10 and straight to x11"

I'm not entirely sure what you mean here. While DX11 may be more complicated than DX9 in some ways (I actually don't know that much about DX9 development so I won't even attempt to compare the two), DX10 is a strict subset of DX11 so while 11 adds more features it really shouldn't be seen as harder to learn than DX10.
Since you mention a "modders kit", I take it you may in fact be referring to the DBPro X10 build? I can imagine that being a mess what with lack of documentation and it (as far as I understand) just basically being additional functionality patched onto the previous DX9 engine rather than being an actual DX10 engine.
I would like to point out that I try my best to make my engine as easy to transition to as possible for previous DBPro users with similar naming of concepts and functions, as well as the fact that I try to write rather comprehensible documentation for each individual function exposed by the plugin. That said there will of course be a learning curve, but if you know DBPro since earlier you can probably get a spinning cube rendered in a minute or two simply by looking at the 3D commands list for the appropriate function names. There are also a set of documented example projects included in the plugin archive that demonstrate various things from basics to more advanced. As the engine matures the number of such example projects will grow to hopefully showcase most raw functionality available in the plugin.


Quote: "Yes, while I personally haven't commented on this thread, I have been following closely."

Thanks, that is nice to know


Quote: "I am writing my first DX11 programs this week. These snippets will have a need for feedback and critique at some point; where am I to post such snippets? Perhaps in the snippet section or in this thread?"

I'm excited to see what you will come up with. While the engine currently lacks collision detection I can give you a tip; using the DX11 GET OBJECT BOUNDING BOX function you can perform your own simple overlap detections much like DBPro's own built-in OBJECT COLLISION function does. There is also a DX11 INTERSECT OBJECT function.
As for where to post your creations I would of course be delighted to see them. Still, given the excessive inactivity of the code snippets board it would perhaps be a nice addition over there (or perhaps not so much, if people never visit it).



As for how the work is currently progressing, I have most of the GPGPU functionality in working order with DX11 now. I will still have to do tests to see whether it will work as-is in DX10 compatibility mode (some things I know will not, others may need some tweaking) and then it's off to write documentation and conjure up an example that is a bit more clever than having the GPU build a gradient image "just because".


Again, thanks for your affirmation guys, I appreciate it


"Why do programmers get Halloween and Christmas mixed up?"
James H
12
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 20th Aug 2014 05:39 Edited at: 20th Aug 2014 07:06
Quote: "I suppose (and hope!) you may be right, but frankly the downwards trend around here with lesser and lesser activity and quite a few spiteful posts about the uselessness of DBPro and even Microsoft and DirectX themselves is a bit off-putting"

Yes the activity may be low but this is at least something that can change. The spiteful posts however wont, there will always be this approach, some out of ignorance, some because they cant have what they want, some because they feel dbp is abandoned and they want more among other reasons. Its a bit like criminal activity in the world, its not something that will ever end.
Yes I was referring to dbpx10 build, but as I didnt progress well with it I felt it would be a big learning curve for me to go to x11, but as you say your making it easier to get on with then perhaps my view was a little unfounded. I can always jump to x11 and then go back to x10 for compatibility of a program for folk who dont have x11 cards, that said its highly unlikely I will produce anything that would need such an effort, originally I got into dbp not to write the game of my dreams but to understand why I cant have the game of my dreams, so it will remain a hobby to me rather than having a goal of producing something a lot of folk would enjoy. I am going to be delving into this over the next few days

EDIT
Just downloaded and installed latest version and tried demos.
Both spinning cubes examples work fine as does skeletal animation and foliage examples.
The instancing example threw an error "Variable 'crlf$' does not exist in program." Remming line 287 out allowed me to run it fine.
Couldnt get the demo for dynamic displacement mapping to work - error is "Cannot find structure 'guiSlider_SetValue:&min' in local declaration at line 1348." Remming this line out only gives more errors within same function so I didnt chase it any further.
Impressive work though
As some examples run fine I dont think the following info will be helpful but thought Id provide it just in case;
win 7 64
dbpro_upgrade_7_7_RC7 (version 1.077)
latest dx version (bf4 "works" in x11 mode - bf4 for me however is plagued with performance and crash issues, runs better in x10 but still a load of **** fingers crossed for next patch a friggin year on..seeing as their last patch halved fps and adds huge cpu spikes)
hardware is;
cpu q6600@2.4Ghz
4 gig ram
xfx 680i lt mobo
evga gtx 750
Same errors for both old and new editor. Full permissions.
Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 20th Aug 2014 13:24 Edited at: 20th Aug 2014 21:54
Yes, I reckon you are right.
I actually never tried DBPX10 (to be honest I remember looking for it and never finding it several years back, I just assumed it was an internal build for FPSCX10 that was just never released to the public). While I do try to adhere to the "dbpro standard" so to say, I also try not to limit the DBPro programmer as much by taking away more advanced options, which is why most functions have several versions that at a first glance can seem to take a lot of weird arguments. There are however default resources such as vertex layouts, samplers, textures, fonts and so on that are used unless you explicitly provide your own so I hope that strikes a nice middle ground between ease of use and capabilities.


Bah, it is annoying that those errors would arise since I paid special attention to trying to remove the source of them. Luckily they are easy to fix and I will do so for the next release.

Quote: "The instancing example threw an error "Variable 'crlf$' does not exist in program." Remming line 287 out allowed me to run it fine."

The crlf() function is from Matrix1Utilities. It inserts a set of clear row and line feed characters, which translates into a new line ("\r\n" in many other languages) so you can replace it with chr$(13) + chr$(10) to just use the core DBPro functions.

Quote: "Couldnt get the demo for dynamic displacement mapping to work - error is "Cannot find structure 'guiSlider_SetValue:&min' in local declaration at line 1348.""

Since the DBPro editor isn't too clever it refers to included files by absolute paths. I have tried to go through the .dbpro files and replace them with relative paths but apparently I missed this one. To fix it you can just remove the included "gui.dba" file and then include the one that resides in the same folder as the rest of the displacement example source. That file contains the DBPro code that handles sliders and other gui elements.

As for your graphics card it should indeed support DX11


"Why do programmers get Halloween and Christmas mixed up?"
James H
12
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 20th Aug 2014 21:24
Ah should of guessed but was to tired to do anything sensible when I checked this out. Thanks
James H
12
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 21st Aug 2014 16:50 Edited at: 21st Aug 2014 16:52
Quote: "Since the DBPro editor isn't too clever it refers to included files by absolute paths. I have tried to go through the .dbpro files and replace them with relative paths but apparently I missed this one. To fix it you can just remove the included "gui.dba" file and then include the one that resides in the same folder as the rest of the displacement example source. That file contains the DBPro code that handles sliders and other gui elements."

This is my error - accidentally hit the ` key at some point when looking for different error in that function and so was missing a line. The true error was a parameter mismatch at line 298 of gui.dba, turns out I needed matrixutils number 07 for max and min commands. works fine now, thought I`d better clear that up in case anyone else who doesnt have it installed followed what you suggested because of my error
This is neat btw
Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 22nd Aug 2014 19:03
So Ziggurat is the name of the plugin? I will refer to it by that name in my snippets.

Chris Tate
DBPro Master
10
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 23rd Aug 2014 23:54
OK; I have either found an error; or have caused the error. Please check to see what I may have done incorrectly.

In this snippet; I have created a small pixelmap for producing images to be used as textures; but when I apply the texture to the objects; the objects disappear.

Uncomment the following line (at 100) to test the texturing: DX11 Set Object Texture sphere, ColourTextures(RND(5))



Rudolpho
13
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 24th Aug 2014 01:14
Quote: "The true error was a parameter mismatch at line 298 of gui.dba, turns out I needed matrixutils number 07 for max and min commands."

Argh, yet again... It's getting hard to tell what is a core DBPro function and what is a M1U function... haha. Thanks for pointing it out, I'll try to revise the examples so that they contain no extrenal library dependencies for the next release.

Quote: "So Ziggurat is the name of the plugin?"

Yes, I thought it would be a fun play on the DB pyramid.

Quote: "OK; I have either found an error; or have caused the error. Please check to see what I may have done incorrectly."

Thanks for pointing that out, it is indeed a fault with the plugin.
It turns out the string table entry for the 3-argument version of DX11 CREATE PIXELMAP accidentally referred the 2-argument function, dropping the colour parameter and creating it with a default 0 pixel values (meaning fully transparent).
This problem has been fixed for the next release which I'm hoping will be ready any day now. As a work-around you can use DX11 SET PIXELMAP PIXEL or supply a colour to DX11 CREATE IMAGE instead.

Again, thanks for pointing these things out
I'm looking forward to more such bug reports as I'm sure there are tonnes hiding in there; sometimes it is just hard to manage to do every possible thing myself in my tests.


"Why do programmers get Halloween and Christmas mixed up?"

Login to post a reply

Server time is: 2019-06-15 21:37:22
Your offset time is: 2019-06-15 21:37:22