Windows RenderTech

Apapappa

Member
Description:
This is a little side thing I work on sometimes, mostly when I want to relax a bit.

I'm making this to prepare a "framework" which I can use whenever I decide to actually make one of the 3D games I have planned.

It is definitely not perfect and has a lot of errors and what not but I think it's gotten to a point where it looks good enough to show, so here it is.

There are lots of features I'd like to add but that will happen slowly over time.

Anyway, feel free to tell me what you think.

Versions:
----------------
v0.04:
Download [360mb] (YYC and VM available):

https://www.dropbox.com/s/snne6i65y20dec4/RenderTech_v0_04.zip?raw=1
Screenshots:


Changes since previous version:
There are way too many things to list all of it so I'll just highlight a few -
Added a completely new scene, intended to be more of an actual game scene than just random stuff everywhere.
Improved performance and visuals all across the board.
Improved the lighting system, now uses a version of BRDF (GGX, Schlick Fresnel, etc), still not sure if I got this looking completely right but it's better than the previous version at least.
Reflections now support sun lighting and shadows.
Water now support sun specular reflections.
Shadows now use 4 cascades instead of 3, improves quality in far distances.
Removed some effects / tests which did not work well or felt a bit useless:
eye adaptation, focus based DOF, custom SSAO objects, noise, bloom streaks, high quality glass (now always on), night mode, ten million point sprites (already know this works now).

Notes on running this:
Running this consumes quite a bit of VRAM (graphics card memory), around 1.2 GB, so just wanted to tell you that in advance.

Notes on assets used:
I did not create most of the textures and models.
The entire scene (minus the random spheres) is from here (San Miguel 2.0): https://casual-effects.com/g3d/data10/index.html#mesh29
The models have been separated and heavily decimated since importing a 600mb .obj file into GM would take a couple of years. ;)
I mostly use the original textures that came with the scene but I have also added extra textures like: normal, metallic/roughness/displacement (not currently implemented)/ambient occlusion, emissive maps.
Some textures have been replaced with new ones from here: https://cc0textures.com/
----------------
Download [80mb] (YYC and VM available):
https://www.dropbox.com/s/n89yhj1ohlkklhx/RenderTech.zip?raw=1
Screenshots:

Notes on assets used:
I did not create most of the textures and the tree model, they are random stuff from the internet which I use for testing purposes.
----------------

!! Warning: !!
Running this requires a pretty "high" end graphics card.
If you have a lower end graphics card / bad cooling or a laptop, run this at your own risk.
I take no responsibility for any burned out graphic cards or laptops.
(none of this should happen anyways)

Made with GMS 1.4.
 
Last edited:

lolslayer

Member
Looks really great, love it, what kind of systems can we expect?

And what have you done to achieve point sprites?
 

Apapappa

Member
Looks really great, love it, what kind of systems can we expect?

And what have you done to achieve point sprites?
Thanks.

I don't really know what systems can be expected.
But what I can do is tell you what I would like to implement (this does not guarantee these will be implemented):
1. Screen Space Reflections.
2. Dual Paraboloid shadow maps for point lights.
3. Dual Paraboloid reflection maps to improve the current spheremapped reflections.
4. Particle Systems using Point Sprites.
5. Weather Effects (probably using something like said particle systems)
6. Better Foliage Interaction. (better bending, maybe dynamic sway forces)
7. Water/Fluid Surface Interactions. (deforming water surface and/or apply ripple effects)
8. Deferred Decals

9. Level Editor and Collision Systems similar to these old versions:
https://www.dropbox.com/s/27zxkmsf1fnidq2/DoomGFXGame_2016.zip?raw=1
https://www.dropbox.com/s/7gsba29nkpagw6r/SqrEngine_2017.zip?raw=1

Both of these contain a level you can edit or walk around in, the levels were made inside these editors.
These are also examples of what kind of game I would probably make using the new editor.

[edit]
I should probably have mentioned that I'm using Doom and Half-Life assets for testing purposes in these two editors.
There are probably random textures from the internet being used aswell.
[end of edit]

10. Animated 3D Models. (not something I'm good at, so this would probably be low priority)
11. Update the Lighting Model since kraifpatrik mentioned it. ;)

As for the point sprites -
I'm using my (horrible) dll to enable DX9 point sprites, submit a vertex buffer using pr_pointlist and HLSL then automatically draws them correctly when using the PSIZE semantic.
The 10 million point sprite test is one VBuffer with 1 million points drawn 10 times at random locations.

Hope that answers your questions. ;)

Needs some work on the lighting model, Phong does not really cut it in 2019, but otherwise looks nice!
Yeah, that's true, it has been added to the feature wishlist, thanks! ^^
 
Last edited:

lolslayer

Member
Thank you for the answer, for point sprites however, I do know a not very well known way to get the to work without DLL's ;)
 

kraifpatrik

Member
I've checked out the SqrEngine_2017 and I have to say that when it's put together like that, it's a lot more impressive! Hopefully we will see a full game made out of that one day.
 

BlueBurn

Member
Oh no...really? Half Life 3 finally leaked? :D
No seriously all those demos look pretty good man, really glad to see another member of the 3D gang.
 

Apapappa

Member
Sorry for the late replies, forgot about it multiple days in a row now...

Thank you for the answer, for point sprites however, I do know a not very well known way to get the to work without DLL's ;)
I have no idea what way that would be. ^^
But it doesn't necessarily matter since it's just 1-2 DLL calls depending on how you use it and I also use the DLL for other things like anisotropic filtering, wireframe, etc so I can't get rid of it either way.

Very nice, man! We certainly have some players in the 3D space now. Awesome to see!
Thanks. ;)

I've checked out the SqrEngine_2017 and I have to say that when it's put together like that, it's a lot more impressive! Hopefully we will see a full game made out of that one day.
Yeah, even though everything is basically squares it still looks pretty detailed, it could be a lot more detailed if more time was spent on it and that is probably what would happen if I made a game using these systems.
Thanks for the feedback! :)

Oh no...really? Half Life 3 finally leaked? :D
No seriously all those demos look pretty good man, really glad to see another member of the 3D gang.
Hopefully Half-Life 3 looks way better than this if it comes out. :p
Thanks for the feedback. ^^
 

lolslayer

Member
I have no idea what way that would be. ^^
But it doesn't necessarily matter since it's just 1-2 DLL calls depending on how you use it and I also use the DLL for other things like anisotropic filtering, wireframe, etc so I can't get rid of it either way.
Ah yeah, understandable, and honestly I don't think it was supposed to be there, I figured it out on accident
 

Apapappa

Member
Hello again, I've spent some more time on this so here is a new version.

I didn't get around to crossing off much from my previous feature list but at least there is now an actual scene and not just random stuff scattered everywhere.

Most of the models use flat normals since I decimated them which broke the smooth normals so flat normals will have to do for now.

Anyway, don't know what else to say so I'll let the pictures speak for me, as always, feel free to tell me what you think. :)

v0.04:
Download [360mb] (YYC and VM available):

https://www.dropbox.com/s/snne6i65y20dec4/RenderTech_v0_04.zip?raw=1
Screenshots:


Changes since previous version:
There are way too many things to list all of it so I'll just highlight a few -
Added a completely new scene, intended to be more of an actual game scene than just random stuff everywhere.
Improved performance and visuals all across the board.
Improved the lighting system, now uses a version of BRDF (GGX, Schlick Fresnel, etc), still not sure if I got this looking completely right but it's better than the previous version at least.
Reflections now support sun lighting and shadows.
Water now support sun specular reflections.
Shadows now use 4 cascades instead of 3, improves quality in far distances.
Removed some effects / tests which did not work well or felt a bit useless:
eye adaptation, focus based DOF, custom SSAO objects, noise, bloom streaks, high quality glass (now always on), night mode, ten million point sprites (already know this works now).

Notes on running this:
Running this consumes quite a bit of VRAM (graphics card memory), around 1.2 GB, so just wanted to tell you that in advance.

Notes on assets used:
I did not create most of the textures and models.
The entire scene (minus the random spheres) is from here (San Miguel 2.0): https://casual-effects.com/g3d/data10/index.html#mesh29
The models have been separated and heavily decimated since importing a 600mb .obj file into GM would take a couple of years. ;)
I mostly use the original textures that came with the scene but I have also added extra textures like: normal, metallic/roughness/displacement (not currently implemented)/ambient occlusion, emissive maps.
Some textures have been replaced with new ones from here: https://cc0textures.com/
 
That looks brilliant, and I get why you've done this. But....er... not sure it really supports the idea that GMS can do 3d, if much of the end result was implemented by yourself. Isn't it now the case that this is more your 3d engine, than it is what YoYo provides out of the box?

Seems like you should get more credit for it, than YoYo for simply making GMS flexible in this manner. Just being nitpicky about "GMS can do 3d like any other engine" - can it? can it really? :)
 

lolslayer

Member
I think he just wants to prove that it is possible at all to make a decent looking 3D game in GM, but yeah, Yoyo barely does anything to help people that want to play around with 3D in GM. Even extending flexibility using basic API functions that would help a lot for 3D, and 2D too, is nowhere to be found.
 

Apapappa

Member
Great stuff! I'm also amazed by the fact that you put this out for free, that's really generous of you!
Thanks. :)
As for this being free, it's pretty much just a testing thing at this point so there's not really anything here to sell.
If I do get around to making an actual game with this at some point it will more than likely not be free though.

That looks brilliant, and I get why you've done this. But....er... not sure it really supports the idea that GMS can do 3d, if much of the end result was implemented by yourself. Isn't it now the case that this is more your 3d engine, than it is what YoYo provides out of the box?

Seems like you should get more credit for it, than YoYo for simply making GMS flexible in this manner. Just being nitpicky about "GMS can do 3d like any other engine" - can it? can it really? :)
I mean.. you're not wrong and I understand what you are saying here but I'm not sure I agree with this part:
"if much of the end result was implemented by yourself"
Now.. I haven't really used other engines but I'm pretty certain that if you're going to make something worthwhile, you're going to have to implement things by yourself.
Are you going to have to implement more things by yourself using GMS than other engines when it comes to 3D? Probably yes, depending on the situation.
Don't like the lighting system in whatever engine you're using? Write a new shader.
Want an SSAO effect or maybe the built in SSAO effect runs too slow? Write a new shader.
So, my point is, no matter what engine you choose or if you write your own engine in C++ or whatever, you're going to have to implement things by yourself.

This thing I've got here is mostly just a matter of "write a new shader", it's using 95% GM functions to run. (probably more than 95%)
I have a custom DLL that I use for a few things, most of which have already been added with GMS2 as built in functions. (gpu_set_cullmode, mipmapping)
Basically the only thing I'm using the DLL for right now is setting the viewport for rendering the shadow maps onto a single surface without buffer surfaces since GMS 1.4 automatically sets the viewport to the entire surface, which may or may not be possible to fix with matrix manipulation but I'm not sure.
In the previous version of this I used the DLL for point sprites as well, but in this version I've switched to quads so that is no longer being used. (still available, just not used right now)
I'd like to get rid of the DLL completely but it is not really possible in GMS 1.4, at least I've not found any other workaround.
And my point with this part is - I'm pretty much only using GM functions for this.

But as I said before, I get what you mean, all of this is not built in or available out of the box.
And I don't really care if something is built in or not, I'd still do the same in any other engine.
So I should probably remove that "GMS can do 3D etc" line from the main post as it comes off different from what I originally meant.

This is just another GMS 3D thread like any other, I'm not trying to prove anything or whatever, I'm just making this so I can use it when I decide to make an actual 3D game.

So, I'm not sure if my point even got across here, this post just became a wall of text because they always do when I get into something.

Bottom line is, you're not really wrong with what you're saying, this is not 100% built in and/or out of the box. :)

I think he just wants to prove that it is possible at all to make a decent looking 3D game in GM, but yeah, Yoyo barely does anything to help people that want to play around with 3D in GM. Even extending flexibility using basic API functions that would help a lot for 3D, and 2D too, is nowhere to be found.
So, as I mentioned in the previous wall of text:
I'm not really trying to prove anything here, it's just another GMS 3D thread where I'm making a "framework" or whatever you could call it which I'll use whenever I decide to make an actual game.
That being said, I agree that they could probably add simple things to make 3D life easier, which could also benefit 2D.
 

Joe Ellis

Member
I agree with what you're saying aswell, in my 3d engine, 90% of it has nothing to do with 3d, cus the main 3d things are already there, they're just not straight out of the box. I don't think anyone making a 3d engine in gamemaker can call it their own. The functions and everything are there, just waiting for someone to start using them, I think it's alot easier than people first think, and seems more advanced than it is to people who haven't done anything like that. Also like you said, it's just as hard\complicated to make a 3d game in any other engine or programming language, people think of a 3d engine as something that's already been made, like cryengine, unreal, unity, but once you get into rendering everything how you want, and having to program all the specific things for your game, I don't think it makes much difference.

Your stuff looks really nice btw, the shadows are exceptional quality, especially how they land on the decals !
 
So, I'm not sure if my point even got across here, this post just became a wall of text because they always do when I get into something.
I wouldn't worry about it. I'm pretty sure most people looking at this thread this will also be curious about behind the scenes details, and that takes some explaining.
 
You mention having made a dll to add mipmapping. I'm interested in adding mipmapping as well as vertex texture sampling to a gms1 project. But I've no idea where to begin with this. Where do you find information on the subject?
 

Apapappa

Member
I agree with what you're saying aswell, in my 3d engine, 90% of it has nothing to do with 3d, cus the main 3d things are already there, they're just not straight out of the box. I don't think anyone making a 3d engine in gamemaker can call it their own. The functions and everything are there, just waiting for someone to start using them, I think it's alot easier than people first think, and seems more advanced than it is to people who haven't done anything like that. Also like you said, it's just as hard\complicated to make a 3d game in any other engine or programming language, people think of a 3d engine as something that's already been made, like cryengine, unreal, unity, but once you get into rendering everything how you want, and having to program all the specific things for your game, I don't think it makes much difference.

Your stuff looks really nice btw, the shadows are exceptional quality, especially how they land on the decals !
Yes, pretty much this, what you said is more or less part of what I was trying to say.
I really can't think of anything to add to this right now so I'll leave it as is.
Also thanks, I'm trying to make everything look as good as I can with what I got.

I wouldn't worry about it. I'm pretty sure most people looking at this thread this will also be curious about behind the scenes details, and that takes some explaining.
Sure, I can understand that.
If people want more behind the scenes details on how everything in this works then I can explain some more.
Like, I dunno, shader / surface "tricks" or how I batch everything so I don't end up with what would probably be thousands of texture swaps (the current number is already quite high and can more than likely be improved) or maybe something else.

You mention having made a dll to add mipmapping. I'm interested in adding mipmapping as well as vertex texture sampling to a gms1 project. But I've no idea where to begin with this. Where do you find information on the subject?
So.. my DLL is not good by any means.
*EVERYTHING* is hardcoded because no matter what I did I could never get sending values to the DLL to work, except pointers they work for whatever reason, might be because I use some version of CodeBlocks and not Visual Studio, I have no idea.
I'm not really the best person to ask about DLLs either, I just try until it works basically, I have pretty much zero experience with the language used here, which would be C++ I think.
But I'll comment the code to the best of my ability.

Example from the DLL:
Code:
// include dependencies
#include <d3d9.h>

// remap "extern "C" __declspec (dllexport)" to "FUNC"
// so we don't have to write that all the time
#define FUNC extern "C" __declspec (dllexport)

// pretty sure this stores the Direct3D9 device inside "DEVICE"
// or it declares this as a device
// I really have no idea at this point it was a long time ago when I made this
LPDIRECT3DDEVICE9 DEVICE;

// Set all samplers to use linear texture filtering including mipmapping
// In an ideal world where I could send numbers and stuff to the DLL
// then there would be no for loop and "i" would be set from GM with shader_get_sampler_index()
// as well as "0" in D3DSAMP_MAXANISOTROPY would be 0-16 anisotropic filtering
// and D3DTEXF_LINEAR could likely be set to from GM since they are constants
FUNC double SetTexFilterLinear(long POINTER)
{
DEVICE = (LPDIRECT3DDEVICE9)POINTER; // Device pointer from GM aka window_device()

for(int i=0; i<=16; i++)
{
DEVICE->SetSamplerState(i,D3DSAMP_MAXANISOTROPY,0);
DEVICE->SetSamplerState(i,D3DSAMP_MIPFILTER,D3DTEXF_LINEAR);
DEVICE->SetSamplerState(i,D3DSAMP_MINFILTER,D3DTEXF_LINEAR); 
DEVICE->SetSamplerState(i,D3DSAMP_MAGFILTER,D3DTEXF_LINEAR);
}

return 1;
}

// And this is the same as the above except it enables 16x anisotropic filtering
FUNC double SetTexFilterAnisotropic16X(long POINTER)
{
DEVICE = (LPDIRECT3DDEVICE9)POINTER;

for(int i=0; i<=16; i++)
{
DEVICE->SetSamplerState(i,D3DSAMP_MAXANISOTROPY,16);
DEVICE->SetSamplerState(i,D3DSAMP_MIPFILTER,D3DTEXF_LINEAR);
DEVICE->SetSamplerState(i,D3DSAMP_MINFILTER,D3DTEXF_ANISOTROPIC);
DEVICE->SetSamplerState(i,D3DSAMP_MAGFILTER,D3DTEXF_LINEAR);
}

return 1;
}
So anyone who actually knows how to write in this language would probably not be happy right now. ;)

As for vertex texture fecthing, I have not tried getting this to work yet but it would be useful for multiple things, so no clue about that one.

And finally, this is how I got started with the DLL:
http://gmc.yoyogames.com/index.php?showtopic=405812

Anyway, hopefully some of this helps.

This look fantastic! Really cool!:)
Thanks, glad you like it. :)
 

Apapappa

Member
Thanks for responding. I was expecint implementation of mipmapping to involve a lot more details. Does d3d automatically create mipmapping textures for you?
It was way easier than I expected as well, there is one drawback with this though -
It does not work on external images, YoYo did not flag these for mipmap generation. (I assume)

So, I guess the answer to your question would be: kinda.
I'm not 100% sure about this but when you create a texture with d3d in C++ or whatever, there is a flag for mipmap generation, without this flag enabled texture filtering does not seem to work at all.

The only thing I have to go on for this is that texture filtering simply did not work for external textures when I tried it.
It does work on surfaces and included images though.

So, to get external textures to work with mipmapping you would have to create them yourself inside a DLL.
 
It was way easier than I expected as well, there is one drawback with this though -
It does not work on external images, YoYo did not flag these for mipmap generation. (I assume)

So, I guess the answer to your question would be: kinda.
I'm not 100% sure about this but when you create a texture with d3d in C++ or whatever, there is a flag for mipmap generation, without this flag enabled texture filtering does not seem to work at all.

The only thing I have to go on for this is that texture filtering simply did not work for external textures when I tried it.
It does work on surfaces and included images though.

So, to get external textures to work with mipmapping you would have to create them yourself inside a DLL.
I'm really surprised that it works with surfaces. I wonder if that means that every time a surface is set as a texture, a mipmapped version of it is recalculated. That's a pretty huge deal if it happens out of our control.
 

Apapappa

Member
I'm really surprised that it works with surfaces. I wonder if that means that every time a surface is set as a texture, a mipmapped version of it is recalculated. That's a pretty huge deal if it happens out of our control.
Well, actually... I'm not sure if the mipmapping part works on surfaces now that I think about it.
Texture filtering definitely does though, using the same DLL method.
 

Lewa

Member
@flyingsaucerinvasion @Apapappa I've got a dll that can load textures from external files, set vertex textures, anisotropic filtering and a few other things, I can send it to you if you want
Wait, what?
I've also managed to write a DLL which enables mipmapping/texture filtering (simply manually calling the given DirectX functions through the DLL) but i never found a way to manually load in textures through a DLL. (Loading in texture data isn't the problem. But i'm not aware of any kind of way of passing this data to GMs internals.)

As others have said, the DLL method neither works with surfaces nor with externally loaded textures (like with textures loaded in through background_add(), etc...)

How did you manage to do it?
 
Last edited:

Joe Ellis

Member
Wait, what?
I've also managed to write a DLL which enables mipmapping/texture filtering (simply manually calling the given DirectX functions through the DLL) but i never found a way to manually load in textures through a DLL. (Loading in texture data isn't the problem. But i'm not aware of any kind of way of passing this data to GMs internals.)

As others have said, the DLL method neither works with surfaces nor with externally loaded textures (like with textures loaded in through background_add(), etc...)

How did you manage to do it?
I paid this guy to make it for me a few years ago, neither of us actually knew how to do it until Mike suggested this thing to us, that turned out to work perfectly.

It basically has texture_load(filename), which returns the pointer into gm, and texture_set(pointer, sampler_slot).
So it just bypasses gm's built in texture system, I don't think there's any way to load textures into that without gm's source code.
The mipmaps get automatically generated for the textures, but it still doesn't work with surfaces,
I think I remember directx9 can't generate mipmaps dynamically for textures already in memory, but I'm not sure.

These are the main parts that deal with this:

Code:
union GMLAddress {
    int gmlValue;
    void* address;
};

IDirect3DTexture9* GMLtoTexture(double addr) {
    GMLAddress ga;
    ga.gmlValue = (int)addr;
    return (IDirect3DTexture9*)(ga.address);
}

double TexturetoGML(IDirect3DTexture9* pTex) {
    GMLAddress ga;
    ga.address = pTex;
    return (double)(ga.gmlValue);
}


double d3dx_texture_load(char* filename)
{
    IDirect3DTexture9* temp = NULL;

    if (FAILED(D3DXCreateTextureFromFile(g_d3dDev, filename, &temp)))
        return -1;

    return TexturetoGML(temp);
}

double d3dx_texture_set(double samplerslot, double TextureAddress)
{
    if (samplerslot<0) return -1;

    int slot = (int)samplerslot;

    g_d3dDev->SetSamplerState(slot, D3DSAMP_ADDRESSU, D3DTADDRESS_WRAP);
    g_d3dDev->SetSamplerState(slot, D3DSAMP_ADDRESSV, D3DTADDRESS_WRAP);
    g_d3dDev->SetTexture(slot, GMLtoTexture(TextureAddress));
    return 0;
}
 

Lewa

Member
I paid this guy to make it for me a few years ago, neither of us actually knew how to do it until Mike suggested this thing to us, that turned out to work perfectly.

It basically has texture_load(filename), which returns the pointer into gm, and texture_set(pointer, sampler_slot).
So it just bypasses gm's built in texture system, I don't think there's any way to load textures into that without gm's source code.
The mipmaps get automatically generated for the textures, but it still doesn't work with surfaces,
I think I remember directx9 can't generate mipmaps dynamically for textures already in memory, but I'm not sure.

These are the main parts that deal with this:

Code:
union GMLAddress {
    int gmlValue;
    void* address;
};

IDirect3DTexture9* GMLtoTexture(double addr) {
    GMLAddress ga;
    ga.gmlValue = (int)addr;
    return (IDirect3DTexture9*)(ga.address);
}

double TexturetoGML(IDirect3DTexture9* pTex) {
    GMLAddress ga;
    ga.address = pTex;
    return (double)(ga.gmlValue);
}


double d3dx_texture_load(char* filename)
{
    IDirect3DTexture9* temp = NULL;

    if (FAILED(D3DXCreateTextureFromFile(g_d3dDev, filename, &temp)))
        return -1;

    return TexturetoGML(temp);
}

double d3dx_texture_set(double samplerslot, double TextureAddress)
{
    if (samplerslot<0) return -1;

    int slot = (int)samplerslot;

    g_d3dDev->SetSamplerState(slot, D3DSAMP_ADDRESSU, D3DTADDRESS_WRAP);
    g_d3dDev->SetSamplerState(slot, D3DSAMP_ADDRESSV, D3DTADDRESS_WRAP);
    g_d3dDev->SetTexture(slot, GMLtoTexture(TextureAddress));
    return 0;
}
I didn't know you can bypass game makers texture system. o_O
So basically Game Makers texture pointers are directly mapped to the Direct3D textures in memory?
Have to test it out once i get a bit of spare time on my hand.
(I suppose this technique also works with GMS 1.4?)

@Joe Ellis

In my opinion, we should start a new thread specifically about expanding graphical capacity through dlls. The community can benefit so much from a really comprehensive look into this. I would spearhead the effort myself, but I have very little knowledge on the subject.
This. Especially the DLL bypass technique is HUGE.
I've searched for such a possibility for a very long time. I couldn't find any kind of information on this topic. (until now.). This warrants it's own thread.
 

Joe Ellis

Member
I'll make the thread in the next few days, I'll link the source code & dll and answer any questions about it, also other people will be welcome to post more dlls\code or help. I'm worried that @Apapappa doesn't want us to keep discussing it here so I'll leave it here for now.
 

Apapappa

Member
I'm just gonna @ everyone involved in recent conversations here since so much has happened since I last checked this thread.
@Joe Ellis @flyingsaucerinvasion @Lewa



@Joe Ellis:
That DLL could definitely be useful but as you said, if you link the source and the dll in the new thread you were all talking about I could just grab it from there, this would probably be the best for everyone if this is something you're still up to do.

And I'm fine with you all discussing this in my thread so don't worry about that.
But it is probably for the better if we start a new one as this would probably benefit everyone better.

Everyone:

I don't really have anything to add to what @flyingsaucerinvasion and @Lewa said, other than the fact that I agree that we should start a new thread dedicated to the subject.
 

Mert

Member
Here's an idea(I don't actually know if that works, but I believe so)
If you can work with @kraifpatrik (also see this topic) you may as well do this from/near the Game Maker's own core, avoiding the need to use a DLL.
There is also a topic about native multi-threading. Maybe you can process/generate data on separate threads.

Plus, all YYC supported platforms may benefit from your work by this, not just Windows platform.

Edit : Oh, didn't see he already is in the topic :D
 

Apapappa

Member
Here's an idea(I don't actually know if that works, but I believe so)
If you can work with @kraifpatrik (also see this topic) you may as well do this from/near the Game Maker's own core, avoiding the need to use a DLL.
There is also a topic about native multi-threading. Maybe you can process/generate data on separate threads.

Plus, all YYC supported platforms may benefit from your work by this, not just Windows platform.

Edit : Oh, didn't see he already is in the topic :D
Sure, these things seem like they could possibly be useful in some cases.
I'd have to look into it more though whenever I have more time to spare on this project.
 

Joe Ellis

Member
@Apapappa @flyingsaucerinvasion @Lewa
Yeah I'm going to make a thread about it, I just need to make an example project that uses all the functions. I'm gonna try and get that done in the next few days. I've written a rough opening post for it, I'm gonna invite anyone else to post info about their dll(s) if they want, either posting a link to a thread or a whole description, I don't want it to be purely my thread about my dll, I want it to be a thread where people can discuss anything graphics dll related
 

Apapappa

Member
@Apapappa @flyingsaucerinvasion @Lewa
Yeah I'm going to make a thread about it, I just need to make an example project that uses all the functions. I'm gonna try and get that done in the next few days. I've written a rough opening post for it, I'm gonna invite anyone else to post info about their dll(s) if they want, either posting a link to a thread or a whole description, I don't want it to be purely my thread about my dll, I want it to be a thread where people can discuss anything graphics dll related
Sure, I'll be waiting for the thread then and possibly post something from my dll if there's anything useful left in it.

We could even take this a step further and combine our dlls into a community driven one which has all the functions or whatever ready to use, if this is something people want and/or are willing to do.
Or just post functions from the source code in the thread then anyone could compile their own dll with the functions they need, again, if this is something people want and/or are willing to do.

Either way, I'll be keeping an eye out for the thread.
 

Apapappa

Member
Hello again.

I decided to spend some more time on this, so this time I've worked on implementing collisions and some minor "physics".

This current example uses the same level from my old SQREngine example from 2017 (available in a post in this thread) and has 200 "physics" actors active in the map.
(also features a bunch of barneys from the half-life alpha moving around kicking footballs and wreaking havoc)

I guess we can call this a stress test since there would probably not be this many moving things active at the same time in an actual game level whenever I get around to making a game of this sort.

There are more than likely a bunch of bugs and what not but it works good enough right now at least.

Here's a *tiny* gif showcasing some of the example:


And here's a link to a playable example:
https://www.dropbox.com/s/9biu7s5025ijk0r/RenderTech_Collisions.zip?raw=1

If you decide to try the example out, feel free to tell me how it runs or if you think I can improve on something or whatever.
 

Apapappa

Member
I got a bit hooked on working on this so here's another update on the collision part of this:
(which will probably turn into the actual editor later)

Highlighted Changes:
Improved general physics performance.
Added raytracing for use with: melee weapons, hitscan weapons, better handling of picking up objects, editor tools and endless other possibilities for effects.
Added object selection and hovering with said raytracing.
Added a Loading Controller which handles loading of maps.
Added a Sector Batching Controller which handles batching all sectors and static object into one vertex buffer per texture.
Added the ability to break objects, like glass in this example.
Throwing objects large enough or with enough speed into other object can now break them depending on object mass.
Created a (very beautiful) melee weapon 3D model for testing fps camera melee weapon effects.
You can now break and push objects with said melee weapon.

Another *tiny* GIF:


Planned Future Update:
Creating and adding a hitscan based weapon (probably a pistol or something) to flesh out shooting mechanics.
Same as above but a projectile based weapon.
Adding some basic particle effects for use when hitting objects.
Basic sector / object editing so making levels is possible again.
Saving / Loading maps with a new better map format.

These are the things I want to get done before returning to Zordak again for a while so I can have a pretty solid base coming back to this again later.


Anyway, that's it for now, this is turning out better than I expected so I'm pretty happy about this.
 

Apapappa

Member
Well, I managed to implement everything I wanted from the previously planned update, and even some more.

The tools are still a bit wonky, as can be seen when I flail about in these new gifs, but they work good enough for now.

Highlighted Changes:

Created a pistol model for the hitscan based weapon and implemented it.
Created a rocket launcher (or something) for the projectile based weapon and implemented that as well. (the projectile is a bit off but it works)
Added sector and object edit modes for the level editor. (with a bunch of included stuff you can customize)
Updated the map file format to a more "edit friendly" format.
Added some more functions to GMEx, like: GetFilesInFolderAsString, GetImageWidthFromFile, GetImageHeightFromFile, CopyFile.
The editor now has a game assets folder (not sandboxed) from which it loads: textures, levels, models.
Added a TextureManager and ModelManager, which updates and loads relevant assets.
Added a filewatcher to TextureManager and ModelManager allowing you to drag and drop textures and models in the game asset folder and have the editor automatically load them. (only .png images and .buf gm buffers supported for now)

And here's some gifs:






I guess that's it.
This may or may not be the final update to this for a while, I'm not sure I want to go down this rabbithole just yet.
 
Top