3D Slow terrain loading. (How to optimize?)

Status
Not open for further replies.
M

Misty

Guest
Ok so it takes 11 seconds to load 4 chunks of terrain....

Mostly this is because of the Gouraud shading I used on the terrain and there are about 20 find_normal calls.
Also, a lot of d3d_model_vertex and ds_grid calls too.

What is the best way to go about optimizing this?

Music to go in the back of your head to help you have a clear mind while you are thinking about this. www.youtube.com/watch?v=Ar09V0FYiIo
 
P

Paolo Mazzon

Guest
"here is my music pls love it"
I don't think anyone is really going to provide meaningful suggestions without any actual code. There are billions of different ways to go about chunk loading, so we need a little to go off here.
 
M

Misty

Guest
"here is my music pls love it"
I don't think anyone is really going to provide meaningful suggestions without any actual code. There are billions of different ways to go about chunk loading, so we need a little to go off here.
The code is basically like this.

Create all empty models and empty grids in the create event.

In the Draw Event, load 1 chunk each frame. (This uses 2 loops.
Loop 1. Set the grid values using ds_set_grid() using a loop.
2. Read then add the grid values to the models in a loop right below it. Also in this loop there are a bunch of find_normal calls in order to smooth normals.

After several frames (and seconds) the model will complete. The loading allows the player to move in real time before the terrain is loaded, but it takes 11 seconds and causes the framerate to be 1 fps.
 

Binsk

Member
It is difficult to help you without code, as Paolo stated. However, there are still some things you can consider that may help speed things up.

Creating and destroying ds_grids can be slow. Make sure you are only using them when needed and try to re-use them when possible.
As for your 3D structuring, you can use d3d_model_* functions to create models, and you can also use vertex buffers. If I am correct in my guess, d3d_model_* functions likely use these vertex buffers behind the scenes. However, since it doesn't know how big your model will be it probably has to resize the buffer often to fit the new vertices; assuming that your models are of decent size. Again, this is just a guess.

You could try using vertex buffers to define your models instead. This way you can use vertex_create_buffer_ext() to specify exactly how much memory needs to be allocated to hold your model before throwing all the data into it. You also will have the benefit of being able to freeze the buffer when done which will make the model render faster.

Those are just a couple thoughts that came to mind.
 

Roa

Member
You could try using vertex buffers to define your models instead. This way you can use vertex_create_buffer_ext() to specify exactly how much memory needs to be allocated to hold your model before throwing all the data into it. You also will have the benefit of being able to freeze the buffer when done which will make the model render faster.

Those are just a couple thoughts that came to mind.
He is talking about loading the chunks, not necessarily rendering, though I could see why you would think that given for some reason he is doing all this in the draw event....

The code is basically like this.

Create all empty models and empty grids in the create event.

In the Draw Event, load 1 chunk each frame. (This uses 2 loops.
Loop 1. Set the grid values using ds_set_grid() using a loop.
2. Read then add the grid values to the models in a loop right below it. Also in this loop there are a bunch of find_normal calls in order to smooth normals.

After several frames (and seconds) the model will complete. The loading allows the player to move in real time before the terrain is loaded, but it takes 11 seconds and causes the framerate to be 1 fps.
Why are you using 2 loops and why are you adding stuff in the draw event? You should do it all all on create or a timer. You should be able to add the grid values and add the vertex buffers in the same path. Also, maybe you should consider some options such as building buffers for a vertex_buffer batch and saving/loading the buffers? creating data in the buffer could be done over time based on users frame rate, and when it is saved, it can be loaded much faster for another time.
 
M

Misty

Guest
I will tell you all why and I will clear some misconceptions.

"Creating and destroying ds_grids can be slow."
They are only created once in the create event. And they are only destroyed at Game End. The creation of them are not the source of the lag, however the modification of them (ds_grid_set()) may very well be.

"use vertex_create_buffer_ext()"
I am using Game Maker 8. Game Maker 8 does not have those functions, but it is a noble suggestion.

"He is talking about the chunks"
Misty is a girl, not a boy, although technically, a tomboy. Tomboy has the word boy in the name, likely causing confusion.

"not necessarily rendering"
In my past days, if I can recall I did vertex buffering before. What Binsk meant is to replace the d3d_model_vertex calls with vertex buffering functions. From what it seems, Binsk understood that it wasn't an issue of the rendering hitting the performance, but the model definitions themselves.

'Why are you using 2 loops"
Quite simply, because it is the easiest and most clear way. First I define the values of the grid, then I close the loop. Then I start a new loop, retrieve the values of the grid and plug them into the model. It is the clearest way to do it, if I did it all in one loop and defined the grid and the mesh at the same time it would cause problems with the vertex smoothing.

"why are you adding stuff in the draw event?"
Due to some strange bug in GM, defining models in the STEP event causes them to be invisible (but only sometimes.) Thus, I define them every frame in the Draw event. I must also be clear - I have not drawn them in the STEP event,simply define their vertices in the step event. And when I do so, when I draw them in the draw event they are invisible.

"You should do it all all on create"

That would be a mistake, because it would freeze and potentially crash the game. It is essential to divy up the workload into frames.

"You should do it in a timer"
I am not sure what the timer function is in Game Maker, I have never heard of it before, are you referring to alarms or timelines?
 

Roa

Member
I was talking about the alarms. You should avoid the step event as it will process that every frame, and even if you use an if statement to skip it, you will still have that check every frame. If you do use step, simply calling the model_clear function or destroying and recreating the model before adding to it will fix that issue of things not properly being added.

But I digress, if you are taking 11 seconds and its too slow for create event, then your system fundamentally, flat out doesn't work and you need to re-think your approach. I've ran other's height maps that pick from a bitmap that load faster..and that is pretty slow. You should really post some code or gmz. There is definitely some things here that can be optimized, but not sure what.

How many cells are you pulling from per loop to make these maps?


Also, you're using gm8 which is pretty much dead. Most members would prefer if your forgot it and moved up. The free edition of studio uses less resources, has more functions and features than pro gm8, and its way way way faster, so much so that they are not even in the same ballpark. Not a lot people can do for speed and 3d when it comes to gm8. I'm not going to lie. When people use to post in the old GMC towards the end of its life, I strictly ignored all request for help on GM8 and told them I would help after they upgraded. You're doing yourself, and everyone here frankly, a disservice by continuing to use legacy software.

Is there a reason you haven't changed?
 
M

Misty

Guest
Pre-create the geometry. Then load into a vertex buffer from file.

You'll be down to a fraction of a second this way ;)
What do you mean by precreate the geometry? Please be more specific. It's getting rather the late in the evening, and all Im starting to be able to think about are sweet blankets of sleep.

you're using gm8 which is pretty much dead.
Is there a reason you haven't changed?
There is a slight lag when typing the code, and the metaphysical aesthetics of it are slightly different from gm8.


I was talking about the alarms. You should avoid the step event as it will process that every frame,
That is the point in the first place. Why would I use alarms?
Ok, in case you were under the assumption that my game continuously lags, I shall say this - the loop system exits the event and no longer lags, once all chunks are achieved. The terrain renders very fast, but loads slow as molasses.

If you do use step, simply calling the model_clear function or destroying and recreating the model before adding to it will fix that issue of things not properly being added.
Model clear didn't help. Its not my code, its a bug in gm8, it doesn't happen in Studio. However I solved it in GM8 by putting it in the Draw Event instead of Step.

But I digress, if you are taking 11 seconds and its too slow for create event, then your system fundamentally, flat out doesn't work and you need to re-think your approach
.
But the system does work, the terrain is fully functional. Carnivores Cityscape took 15 minutes to load so 11 seconds is quite the achievement compared to that.

I've ran other's height maps that pick from a bitmap that load faster..and that is pretty slow. You should really post some code or gmz. There is definitely some things here that can be optimized, but not sure what.

How many cells are you pulling from per loop to make these maps?
32x32 per chunk, 4 chunks.
 
P

Paolo Mazzon

Guest
Okay, these people are trying to help you and you're making them play hot and cold with your code. What is in your code that you are so afraid to show?
 
M

Misty

Guest
I have been very clear and transparent with the basic jist of things and I am fairly sure you can extrapolate exactly what needs to be done given the information you have been given.
 
P

Paolo Mazzon

Guest
I am fairly sure you can extrapolate exactly what needs to be done given the information you have been given.
Oh thank the lord for this blessed information Misty has bestowed upon us. It is quite the honor to be allowed to provide assistance to someone of nobility such as yourself. And being open about your issue you seek help for? Well, aren't we just the luckiest bunch?

btw, that was a pretty spicy question dodge you just pulled there
 
M

Misty

Guest
Oh thank the lord for this blessed information Misty has bestowed upon us. It is quite the honor to be allowed to provide assistance to someone of nobility such as yourself. And being open about your issue you seek help for? Well, aren't we just the luckiest bunch?

btw, that was a pretty spicy question dodge you just pulled there
Interesting that you asked that. As a matter of fact, I have some amazing results.

Firstly, I would like to note that most of the posters here, have been, markedly incorrect. Though well meaning, their advice shall be, how shall we say, kindly putting it - lost upon the shore.

In fact the main cause of lag was NOT the d3d_model definitions at all, which only took 0.3 seconds. Nor, even the ds_grid calls, which took about 0.6 seconds.
In fact, the main cause of lag was merely the calling of scripts....yes you heard me right! Merely calling the scripts and retrieving variables from scripts was enough to halve the performance.
It was clunky, but I managed to get rid of alot of script calls, using direct code instead.

I will report back on any further performance achievements, right now I have it down to 6 seconds, trying for more.
 
B

Braffolk

Guest
Have you tried identifying which part is the slowest? I assume it is modelling. Use time functions to check how much time each part of the loading proccess takes.
 

GMWolf

aka fel666
Just dont use gamemaker 8.
with just the standard GMStudio runner your game will run 10x faster, and with the yyc it will be anywhere for 10 to 100x faster!

Also, you did not give much information for us to help you. at least give us a more detailed version of your algorithm...
I wrote a number of terrain system, including one that would load chunks in the step event. By more cleverly distributing calculation steps, i was able to more than halve the time it took to generate terrain.
I was able to do a lot of optimizations as my first system would generate 5 different perlin maps to generate the terrain. I realized i could cheat a little and have my perlin method generate a set of values rather than just one value for each x, and y positions. In the end i was able to generate 16 32x32 chunks in about a second, rather nice for a terran system with height, heat, precipitation, water level and vegetation maps. Im sure that using compute shaders i could have greatly improved the performance, but it gets a little messy in GM.

That is to say, there is a million different ways to speed up algorithms based on the situation. maybe your code will help us identify one.
I suspect you wouldnt want to share your code because its your next great project and all, but many people probably gave out much better code so i doubt any one would be interested in stealing yours (why would you be asking for help otherwise?)
 
Last edited:
M

Misty

Guest
Just dont use gamemaker 8.
with just the standard GMStudio runner your game will run 10x faster, and with the yyc it will be anywhere for 10 to 100x faster!

Also, you did not give much information for us to help you. at least give us a more detailed version of your algorithm...
I wrote a number of terrain system, including one that would load chunks in the step event. By more cleverly distributing calculation steps, i was able to more than halve the time it took to generate terrain.
I was able to do a lot of optimizations as my first system would generate 5 different perlin maps to generate the terrain. I realized i could cheat a little and have my perlin method generate a set of values rather than just one value for each x, and y positions. In the end i was able to generate 16 32x32 chunks in about a second, rather nice for a terran system with height, heat, precipitation, water level and vegetation maps. Im sure that using compute shaders i could have greatly improved the performance, but it gets a little messy in GM.

That is to say, there is a million different ways to speed up algorithms based on the situation. maybe your code will help us identify one.
I suspect you wouldnt want to share your code because its your next great project and all, but many people probably gave out much better code so i doubt any one would be interested in stealing yours (why would you be asking for help otherwise?)
Question is, did your system have vertex normal smoothing?

By more cleverly distributing calculation steps, i was able to more than halve the time it took to generate terrain.
What exactly did you do?

I suspect you wouldnt want to share your code because its your next great project and all, but many people probably gave out much better code so i doubt any one would be interested in stealing yours (why would you be asking for help otherwise?)
Also, 1 second on your computer could very well mean 10 seconds on mine, so for all we know my terrain is more optimized than yours.
 

GMWolf

aka fel666
Question is, did your system have vertex normal smoothing?
Yes. It used phong shading using smoothed normals that i would bake into the vertex data.
What exactly did you do?
The system would load multiple chunks at a time. Because i used multiple maps, i woul dcache some of the perlin generation data and re-use it in different chunks for a different map. This meant that i had a lot less calculations to do, at the expense of slighly less 'random' terrain, though no actual artifacts where noticable. THis however can only be used in a situation where each chunk needs separate maps.
Anothe rmajor feature was to have "loading steps". Each chunk would in turn ask for a loading step, and load part of the chunk. The system would stop distibuting it once the step was above 90% over (leaving enough time to draw the game).
Also, 1 second on your computer could very well mean 10 seconds on mine, so for all we know my terrain is more optimized than yours.
Thats a factor of 10 difference. How old must your CPU be to be 10 times slower slower than a Phenom II? (this was on my older pc).
Besides, for all we know you could have written a system on par with AAA engines available today. However with no code to examin i can only guess you what ineficiencies are in your system.
Besides, a relunctance to share code is a pretty clear indication that you havent been programming for all too long anyways :)
 
M

Misty

Guest
Been programming for over 10 years. I love when people make erroneous correlations.

Lets make a new erroneous correlation: All people who put jelly on their toast, are from the planet Jupiter and are Capricorns.

Also, I use Gouraud shading, not Phong, phong is pretty much gauranteed to require shaders and done on the GPU, therefore of course your calculations are going to be faster, sounds like you calculate the smoothing via some per pixel shader, then baked to some surface, whereas my smoothing calculations are calculated based on the polygon coordinates. Also I dont use perlin noise so that doesn't help me much.

Phenom II is a much better processesor than mine, it has 4 cores and mine has half that. In addition to having higher Ghz cycles, it also probably has superior architecture as well.

Let me put it this way...my computer struggles to make the text show up as I type it forum posts...
 

GMWolf

aka fel666
I use Gouraud shading, not Phong
Phong shading is a shading model. Gouraud shading just means the values are interpolated linearly along the triangle faces (something your shader will do by default). Gouraud shading is not a shading model, more of a technique.
https://en.wikipedia.org/wiki/Gouraud_shading <- notice how the use the example of Gouraud shading with the Phong lighting model.

Phenom II is a much better processesor than mine, it has 4 cores and mine has half that. In addition to having higher Ghz cycles, it also probably has superior architecture as well.
Im terribly sorry to hear that you must be developing with such a low end cpu. and i highly encourage you to purchace a new one! (the phenom II was $60 when i got mine, probably much cheaper these days).

[edit]
I just realized my mistake: I meant to say i used the Phong reflection model on each vertex. Not phong shading, strictly speaking.

Also, have you switched to studio? On such a low power cpu, i doubt you can afford to run an emulator witten in an emulated language... (which is what GM8 does).
Studio offeres the YYC, which should help tremendously with loops.

You may also want to consider writing a DLL to generate the terrain and make use of threads. You could supply the DLL with a pointer to a GM buffer, and ask it to fill it up with vertex data. All you have to do then is query the dll every few steps and build the model up. (in GMStudio, there is a single method to build a vertex buffer from a regular buffer. very handy!)
A DLL would perform much better than GML code.
Threads would allow your models to load faster (much less overhead) and keep your game running silky smooth even when loading a bunch of chunks. It would also offer greater performance on CPU's with higher core counts.

[edit once more]
Unless my reading skills are as terrible as always: You havent given us a clear reason as to why you have not shared your code. May i ask why? (only the code relevant to the terrain is necessary...)
 
Last edited:
M

Misty

Guest
Phong shading is a shading model. Gouraud shading just means the values are interpolated linearly along the triangle faces (something your shader will do by default). Gouraud shading is not a shading model, more of a technique.
https://en.wikipedia.org/wiki/Gouraud_shading <- notice how the use the example of Gouraud shading with the Phong lighting model.
Gm doesn't have inherent vertex normal smoothing though.


Im terribly sorry to hear that you must be developing with such a low end cpu. and i highly encourage you to purchace a new one! (the phenom II was $60 when i got mine, probably much cheaper these days).
Got a laptop, so I can't install any custom cpu's.
And it's a good thing in my opinion, building it on the slowest computer you can find makes sure the game can't lag on anybody's computer.
Keep in mind this is 2016...the probability cluster has greater spanning...people have slower computers than I do this laptop was somewhat higher end when I got it. So even if it doesn't lag on mine, it can still lag on others.


Also, have you switched to studio? On such a low power cpu, i doubt you can afford to run an emulator witten in an emulated language... (which is what GM8 does).
Studio offeres the YYC, which should help tremendously with loops.
I have studio but I don't feel like using it, for metaphysical reasons.

You may also want to consider writing a DLL to generate the terrain and make use of threads. You could supply the DLL with a pointer to a GM buffer, and ask it to fill it up with vertex data. All you have to do then is query the dll every few steps and build the model up. (in GMStudio, there is a single method to build a vertex buffer from a regular buffer. very handy!)
A DLL would perform much better than GML code.
Threads would allow your models to load faster (much less overhead) and keep your game running silky smooth even when loading a bunch of chunks. It would also offer greater performance on CPU's with higher core counts.
When the time comes, I will consider making a dll, though I much prefer games which have everything you need internally. Currently I am overburdened and just getting the terrain to load in the first place.
When it comes time to make the dll, I never learned how to make DLLs, so, if you like, I would rather pay you 5 dollars and have you make the dll for me.
 

GMWolf

aka fel666
Gm doesn't have inherent vertex normal smoothing though.
In my edit i point out that i meant to say i used the Phong shading model on each vertex, and baked that value into the vertex data (using a colour attribute).
The shader will then linearily interpolate this color attribute and pass this colour fragment into the fragment shader.
The lighting is all done when generating the terrain. (this does limit it to having static lighting.)

I have studio but I don't feel like using it, for metaphysical reasons.
... ok - but you are missing out. better tell the ghosts and other apparitions to leave you alone so you can squezze a bit more power out of your pc

I never learned how to make DLLs, so, if you like, I would rather pay you 5 dollars and have you make the dll for me
Making a DLL is not too different from regular C/C++ programming. So if you already know the language the rest is relativly straight forwards if you have a tutorial at hand.
5$ isnt worth my time. besides, i dont have much experience in C++, and i aint confident enough to build a terrain system in it.
 
M

Misty

Guest
Making a DLL is not too different from regular C/C++ programming. So if you already know the language the rest is relativly straight forwards if you have a tutorial at hand.
5$ isnt worth my time. besides, i dont have much experience in C++, and i aint confident enough to build a terrain system in it.
Key is to start simple, start small. First, you make a DLL that does 2+2=4, next, one that does basic arrays, so on and so forth, and you move on from there.
 

Roa

Member
And it's a good thing in my opinion, building it on the slowest computer you can find makes sure the game can't lag on anybody's computer.
Keep in mind this is 2016...the probability cluster has greater spanning...people have slower computers than I do this laptop was somewhat higher end when I got it. So even if it doesn't lag on mine, it can still lag on others.
This is terrible reasoning. No one cares or is irrational enough for gaming on anything less, especially in 3d. You should get a relatively cheap modern system. Building for the lowest common denominator stifles creative work flow and it will be a crap experience for those people anyways, which are such a minute group.

Right now, you can buy a case, prepackaged with a PSU for 40, 8 gigs of ram for 30 bucks, the latest fm2 APU for 80 and a M board for 50. Less than 250 bucks to get a system that runs games from 2008 at max.


And believe me, I avoided GMS for a few months for comfort reasons too, but then I realized how stupid I was being. There is no way I could ever go back. Its hard to imagine just 4 years ago I was adamantly content with gm8

edit
These quotes are so broken Noct lol
 
Last edited:

hippyman

Member
Also, 1 second on your computer could very well mean 10 seconds on mine, so for all we know my terrain is more optimized than yours.
Then why are you asking for help? Another prime example of Misty on his/her high horse.

You came here for programming advice on how to optimize your terrain system but it's "more optimized than his" so you're set. Stop being such a try hard troll and just respect the community. Everybody here just wants to help and you just want to argue.
 

GMWolf

aka fel666
Key is to start simple, start small. First, you make a DLL that does 2+2=4, next, one that does basic arrays, so on and so forth, and you move on from there.
Indeed, i already built a couple (useless) DLL's to add numbers and such, but havent found the need to continue making more complicated onse as i have moved my more computationally intense projects to Java and c#, which both offer great performance.

Back to terrain:
I dont think you have mentioned your method of generating the heightmap. (im assuming you are creating a heightmap based terrain, no voxels and iso surfaces).
Depending on the way you generate it, many optimiztions could be made!
I would also like to know how you achieve your lighting. is it baked into textures or geometry?

I avoided GMS for a few months for comfort reasons too, but then I realized how stupid I was being. There is no way I could ever go back. Its hard to imagine just 4 years ago I was adamantly content with gm8
You can make GMS have a GM8 skin and colour coding. and the IDE should run better on your pc than the GM8 IDE. Not to mention all these horrid functions they made obsolete (if those are the reason you stick with GM8, you have been programming with rather poor style.)
The 3d support of GMS is also ways better than GM8's.
 
M

Misty

Guest
This is terrible reasoning. No one cares or is irrational enough for gaming on anything less, especially in 3d. You should get a relatively cheap modern system. Building for the lowest common denominator stifles creative work flow and it will be a crap experience for those people anyways, which are such a minute group.
Crap experience? My computer can run Quake 3 just fine, and in my opinion those are all the level of graphics games need, anything else begins to overburden the developer with detail, just look at Quake 4, supposed "progress", yet much aesthetically inferior to Quake 3 in my opinion.

Right now, you can buy a case, prepackaged with a PSU for 40, 8 gigs of ram for 30 bucks, the latest fm2 APU for 80 and a M board for 50. Less than 250 bucks to get a system that runs games from 2008 at max.
That's 250 dollars more than I can afford.

And believe me, I avoided GMS for a few months for comfort reasons too, but then I realized how stupid I was being. There is no way I could ever go back. Its hard to imagine just 4 years ago I was adamantly content with gm8
You weren't being stupid and here's why...first of all, it's not stupid to sit on the couch on the fence and comfort yourself, metaphorically speaking, second of all, by limiting yourself to gm8's standards, you make your game that much more efficient and optimized, and when it goes to GM STUDIO, you can apply all of the special optimizations such as vertex buffers to make it run even faster

Then why are you asking for help? Another prime example of Misty on his/her high horse.

You came here for programming advice on how to optimize your terrain system but it's "more optimized than his" so you're set.
Incorrect. I only said it is potentially more optimized than his, and even if it is, there is still room for it to get better.

Stop being such a try hard troll and just respect the community. Everybody here just wants to help and you just want to argue.
More accusations. We are having a rational discussion over here like civilized individuals, then you come blazing over here with the disruptive accusations. Give respect and get respect. The one who's lurking under the bridge is not me, but you.


I dont think you have mentioned your method of generating the heightmap. (im assuming you are creating a heightmap based terrain, no voxels and iso surfaces).
Depending on the way you generate it, many optimiztions could be made!
Secret of the trade at the moment, but I will hint that it has something to do with instanciation.
I would also like to know how you achieve your lighting. is it baked into textures or geometry?
Simple directional lighting and d3d_model_vertex_normal definitions.


You can make GMS have a GM8 skin and colour coding.
Still, it's just not the same.

and the IDE should run better on your pc than the GM8 IDE. Not to mention all these horrid functions they made obsolete (if those are the reason you stick with GM8, you have been programming with rather poor style.)
Oh heck no, no variable_local_set for me.
 
L

Lotias

Guest
by limiting yourself to gm8's standards, you make your game that much more efficient and optimized,
No you aren't. You're making it worse, because GM8's standards were worse. It's better if you just start in GM:S in the first place.

Oh heck no, no variable_local_set for me.
This is why. Variable_local_set is for badly programmed situations you shouldn't even put yourself in. GM:S actually enforces better habits.


Still, it's just not the same.
You're right - it's better!
 
M

Misty

Guest
No you aren't. You're making it worse, because GM8's standards were worse. It's better if you just start in GM:S in the first place.


This is why. Variable_local_set is for badly programmed situations you shouldn't even put yourself in. GM:S actually enforces better habits.



You're right - it's better!
Here's the thing - it's like physical exertion. Sure GM8's standards are worse, which is precisely the point - when you port it to GM STUDIO it's that much better. Lifting weights weakens and exerts the muscles, in order to strengthen them later on.
 
L

Lotias

Guest
Here's the thing - it's like physical exertion. Sure GM8's standards are worse, which is precisely the point - when you port it to GM STUDIO it's that much better. Lifting weights weakens and exerts the muscles, in order to strengthen them later on.
Not true. When you port it to GM:S it's that much more incompatible. Physical exertion is a whole different thing and can't be compared. Taking advantage of GM:S's speed and standards improvements is what makes your code better, not limiting yourself to something that's outdated and not even supported anymore. This thread should honestly be closed, because it's about a legacy version of GM that YoYoGames just doesn't support anymore.
 
M

Misty

Guest
Not true. When you port it to GM:S it's that much more incompatible. Physical exertion is a whole different thing and can't be compared. Taking advantage of GM:S's speed and standards improvements is what makes your code better, not limiting yourself to something that's outdated and not even supported anymore.
As long as you familiarize and memorize the basic gist of GM Studio, you shouldn't have compatibility problems. I know I don't run into very many compatibility problems at all.

This thread should honestly be closed, because it's about a legacy version of GM that YoYoGames just doesn't support anymore.
It's still essentially the same code and code theory.
 
L

Lotias

Guest
As long as you familiarize and memorize the basic gist of GM Studio, you shouldn't have compatibility problems. I know I don't run into very many compatibility problems at all.



It's still essentially the same code and code theory.
No it isn't. And you still haven't given people enough detail to help you. There's literally no real reason you shouldn't be using GM:S.
 

GMWolf

aka fel666
Secret of the trade at the moment, but I will hint that it has something to do with instanciation.
Secret of the trade? Are you a profesional developer working under a company with active NDAs or something? That really doesnt help. Why keep your code secret?
Besides, instantiation? Thats very slow, no matter the language.

when you port it to GM STUDIO
Thats not true. Trust me, i have done it myself.
Sure, the gm8 game will run better in gms, but it wont run better than code designed for GMS.
GMS brings new features, such as vertex buffers, vertex formats and memory buffers that allow you to use dufferent, much more efficient algorithms.
 
M

Misty

Guest
No it isn't. And you still haven't given people enough detail to help you. There's literally no real reason you shouldn't be using GM:S.
It's real for me. I simply feel more comfortable using GM8 due to subtleties of the aesthetics.

The code is also the same for me.

GMS brings new features, such as vertex buffers, vertex formats and memory buffers that allow you to use dufferent, much more efficient algorithms.
Vertex buffers won't help me too much, as the prime lag is, as I said earlier, not from the d3d_model definitions.
 

hippyman

Member
This thread should honestly be closed, because it's about a legacy version of GM that YoYoGames just doesn't support anymore.
That would be the correct thing to do as the poster refuses advice from anybody again and is too stubborn to accept that software is updated for a reason. But unfortunately our great friend Misty is pretty good at riding the line.
 

GMWolf

aka fel666
It's still essentially the same code and code theory.
It's real for me. I simply feel more comfortable using GM8 due to subtleties of the aesthetics.

The code is also the same for me
Again, GMS isnt just a better runner and shaders... Its many more features.
GMS gives you lower level access when it comes to graphics, which allows for much faster vertex building, amongst other many new features more or less related to 3d terrain.

Subtleties of the aesthetics? Ok, more and i may report this thread as a troll because im starting to see it as just that.
 
M

Misty

Guest
I have done nothing wrong and there is no reason to assert your will over me like this. The thread shall remain open, unless if for some reason we are not allowed to make threads about gm8.
 
L

Lotias

Guest
I have done nothing wrong and there is no reason to assert your will over me like this. The thread shall remain open, unless if for some reason we are not allowed to make threads about gm8.
It's not officially supported. GM8 threads weren't allowed on the previous forums either.
 

BLang

Member
If you feel comfortable with GM8, that's just how it is. But don't expect to make miracles happen with it. Chances are, even if you optimized it to an unbelievable extent, it would still load slow.
 

GMWolf

aka fel666
It's not officially supported. GM8 threads weren't allowed on the previous forums either.
I just checked the forum rules and havent found anything about GM8 (maybe i missed it)
I do believe this thread to be rather useless however and is detracting from my sleep (i cant let go), so having it closed wouldnt be too bad.
 
A

AlphaChannel

Guest
Give respect and get respect.
I have done nothing wrong and there is no reason to assert your will over me like this. The thread shall remain open, unless if for some reason we are not allowed to make threads about gm8.
Treating people who are trying to help you badly is not only disrespectful but plain ungrateful to all those who took the time to try and help you.
Also you aren't the one to decide whether this thread remains open.
 
L

Lotias

Guest
I just checked the forum rules and havent found anything about GM8 (maybe i missed it)
I do believe this thread to be rather useless however and is detracting from my sleep (i cant let go), so having it closed wouldnt be too bad.
Threads regarding GM8 and earlier were closed and people were told to use the latest version before asking a question on the forums. That's how I remember it.
 
M

Misty

Guest
Treating people who are trying to help you badly is not only disrespectful but plain ungrateful to all those who took the time to try and help you.
Also you aren't the one to decide whether this thread remains open.
Don't see how I've treated anyone badly, I'm not the one creating accusations and disrupting civilized discussions.

I see from your post count, that you made your account just to make this one post.
 
L

Lotias

Guest
Don't see how I've treated anyone badly, I'm not the one creating accusations and disrupting civilized discussions.
You won't give people enough detail and claim your solution might already be better, rather than trying it out, when someone tries to help. Then people suggest using the faster Game Maker and you deny that too. It's not surprising that people are frustrated, and it's not surprising that you aren't finding much help.
 

slayer 64

Member
gm8 had the BEST file functions, I tell ya...

there is a nice stupid fast way to calc and smooth normals with gms ds grids....
 
Status
Not open for further replies.
Top