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

Discussion in 'Programming' started by Misty, Jun 29, 2016.

Thread Status:
Not open for further replies.
  1. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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
     
  2. Paolo Mazzon

    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.
     
  3. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.
     
  4. Paolo Mazzon

    Paolo Mazzon Guest

     
  5. Binsk

    Binsk Member

    Joined:
    Jun 22, 2016
    Posts:
    595
    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.
     
  6. Roa

    Roa Member

    Joined:
    Jun 20, 2016
    Posts:
    560
    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....

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

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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?
     
  8. Roa

    Roa Member

    Joined:
    Jun 20, 2016
    Posts:
    560
    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?
     
  9. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.

    There is a slight lag when typing the code, and the metaphysical aesthetics of it are slightly different from gm8.


    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.

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

    32x32 per chunk, 4 chunks.
     
  10. Paolo Mazzon

    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?
     
    elementbound likes this.
  11. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.
     
    Xer0botXer0 likes this.
  12. Paolo Mazzon

    Paolo Mazzon 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
     
    elementbound and Xer0botXer0 like this.
  13. icuurd12b42

    icuurd12b42 TMC Founder GMC Elder

    Joined:
    Apr 22, 2016
    Posts:
    1,839
    buffer_load_async

    That's the answer to all your troubles...
    you make your terrains from a vertex buffer, you jam it in a buffer,
    buffer_create_from_vertex_buffer
    you save the buffer...

    You load it with async load...

    once you get the async load event you transfer the buffer back to a vertex buffer for drawing
    vertex_create_buffer_from_buffer
     
    Galladhan and elementbound like this.
  14. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.
     
  15. Braffolk

    Braffolk Member

    Joined:
    Jun 20, 2016
    Posts:
    51
    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.
     
    elementbound likes this.
  16. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    Um...
     
  17. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,440
    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: Jun 30, 2016
    Galladhan and Braffolk like this.
  18. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    Question is, did your system have vertex normal smoothing?

    What exactly did you do?

    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.
     
  19. NoobsWeStand

    NoobsWeStand Member

    Joined:
    Jun 20, 2016
    Posts:
    143
    by doing something like this:

    Code:
    var _time=current_time;
    
    ----CODE-----
    
    show_message(current_time-_time)
     
  20. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,440
    Yes. It used phong shading using smoothed normals that i would bake into the vertex data.
    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).
    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 :)
     
    Galladhan likes this.
  21. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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...
     
  22. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,440
    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.

    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: Jul 1, 2016
    Galladhan likes this.
  23. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    Gm doesn't have inherent vertex normal smoothing though.


    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.


    I have studio but I don't feel like using it, for metaphysical reasons.

    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.
     
  24. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,440
    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.)

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

    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.
     
    Annoyed Grunt likes this.
  25. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.
     
  26. Roa

    Roa Member

    Joined:
    Jun 20, 2016
    Posts:
    560
    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: Jul 1, 2016
  27. hippyman

    hippyman Member

    Joined:
    Jun 20, 2016
    Posts:
    565
    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.
     
    Paolo Mazzon likes this.
  28. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,440
    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?

    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.
     
  29. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.

    That's 250 dollars more than I can afford.

    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

    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.

    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.


    Secret of the trade at the moment, but I will hint that it has something to do with instanciation.
    Simple directional lighting and d3d_model_vertex_normal definitions.


    Still, it's just not the same.

    Oh heck no, no variable_local_set for me.
     
  30. Lotias

    Lotias Member

    Joined:
    Jun 20, 2016
    Posts:
    87
    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!
     
  31. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.
     
  32. Lotias

    Lotias Member

    Joined:
    Jun 20, 2016
    Posts:
    87
    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.
     
    hippyman likes this.
  33. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.
     
  34. Lotias

    Lotias Member

    Joined:
    Jun 20, 2016
    Posts:
    87
    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.
     
  35. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,440
    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.

    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.
     
  36. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.

    Vertex buffers won't help me too much, as the prime lag is, as I said earlier, not from the d3d_model definitions.
     
  37. Lotias

    Lotias Member

    Joined:
    Jun 20, 2016
    Posts:
    87
    Then there's no discussion to be had and this thread should be closed.
     
  38. hippyman

    hippyman Member

    Joined:
    Jun 20, 2016
    Posts:
    565
    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.
     
    RichHopefulComposer likes this.
  39. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,440
    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.
     
    RichHopefulComposer likes this.
  40. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.
     
  41. Lotias

    Lotias Member

    Joined:
    Jun 20, 2016
    Posts:
    87
    It's not officially supported. GM8 threads weren't allowed on the previous forums either.
     
    RichHopefulComposer likes this.
  42. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    Oh, well in that case, I shall report it myself.
     
  43. BLang

    BLang Member

    Joined:
    Jun 21, 2016
    Posts:
    109
    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.
     
  44. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,440
    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.
     
    RichHopefulComposer likes this.
  45. AlphaChannel

    AlphaChannel Member

    Joined:
    Jun 30, 2016
    Posts:
    20
    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.
     
    RichHopefulComposer likes this.
  46. Lotias

    Lotias Member

    Joined:
    Jun 20, 2016
    Posts:
    87
    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.
     
  47. Misty

    Misty Member

    Joined:
    Jun 22, 2016
    Posts:
    1,024
    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.
     
  48. Lotias

    Lotias Member

    Joined:
    Jun 20, 2016
    Posts:
    87
    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.
     
  49. slayer 64

    slayer 64 Member

    Joined:
    Jun 26, 2016
    Posts:
    69
    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....
     
  50. AlphaChannel

    AlphaChannel Member

    Joined:
    Jun 30, 2016
    Posts:
    20
    Posts in off topic don't count in the total. Just saying... I find it funny how you seem to believe I would go through the trouble just to give an opinion.
     
    RichHopefulComposer and Roa like this.
Thread Status:
Not open for further replies.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice