This actually goes back to why the issue isn't YoYoGames removing features. If they wanted to take GM in a fundamentally different direction, why the hell only go half way? They've gone with a pseudo clone, they would be miles ahead of themselves right now had they done this since the beginning of their take over and with much better reward too.

You got to understand GM came out in the 90's, 1999 to be specific, though the actual original Game Maker, not GameMaker, came out in 1992 hence the reason why they've changed their name to avoid a lawsuit, and has not changed pretty much at all since then.

Here is GM 2, 3, 7, and Studio.


But as for modern game design, the whole point of GM is to introduce people to game programming, such primitive ways of doing raster graphics have long been obsolete. There are also places where a revamp to the code base would lead to simpler, more optimal design of games as well, this would be a positive for learning, instead of how it teaches bad habits that you need to unteach yourself when moving to other tools and real programming languages.

Not going atm, discussing future of LGM.

Removing drag & drop might not be a good idea,

I never said remove DND, I said allow two extra resource types, sources and headers, so you can code objects your own way.

Not everyone learns quickly or is familiar with all the technical jargon and coding, I think that was the top selling point with GM, easy to use interface, fast learning curve, etc.

Right, that is why it should be redesigned to focus on helping them understand modern game design, not raster graphics from the 90's. The difference is you only see draw_() functions which are raster graphics in programs like Windows Forms/Java/etc or basically Software, game engines are Hardware, well even software is becoming Hardware now, i.e. JavaFX/Qt

So if I am understanding correctly you are talking about the LGM aspect of the program right ? 

No, functions and compiling are all offered by ENIGMA. Since Studio does not have an IDE besides the really outdated GM4Mac, we distribute LateralGM separately as well. So even if people don't want to use ENIGMA they have an IDE they can use to edit their GM projects on other operating systems, but they can't run them, make sense?

But that was all hypothetical, the project here does what people want it to do. My only point is that GM's functions are verbose and could be redesigned to be more consistent and more powerful, LateralGM's interface also suffers from having options for every single GM version at one time, a result of its development having never been 1 to 1 with GM's.

Can you give examples as to what you can do so much better ?

Sure.

1) Change all window functions to accept a window id, implement the function window_create(), so basically multiple window management
2) Design a uniform dialog system that allows people to basically create their own GUI programs and dialogs, instead of shitty prebuilt ones that work very funky
3) Drop off GMK, allowing you to put resources wherever you want, so basically have a sprite and an object right next to each other in the same folder
4) Redesign paths to allow branching and not be strictly linear
5) Allow sources/header file resources so that you can easily compile C++ directly inside your game, or write objects without drag and drop by sub-classing object_basic
6) Redesign the whole drawing system for modern graphics programming, so basically dynamic draw_text or draw_sprite would be replaced with gui_create_label() and sprite_batch_begin()/end() respectively, just like every other game engine made in the last decade.
7) Make all functions consistent, i.e. vertex_end() returns the id for a vertex buffer in Studio instead of vertex_create_buffer();, like one would assume because of d3d_model_create()

There is so much more I would do too.

Hah that don't look half as bad as Super Mario LSD.

lol it was the buggy version of Project Mario before it was fully fixed up.

I am glad you understand where I am coming from, but with that said, I do not plan on doing it any time soon until it becomes absolutely necessary, where it starts getting in the way of performance and stuff.

I especially would not drop it before YYG has, they did drop their 820 exporter, when they realized how fucked up they made it, but they do still allow importing which auto converts to GMX.

The point here is to lay out LGM's future development in a way that would not leave the last GMK supporting revision extremely feature lacking. In other words, we're talking way down the road once Java 6 is completely dead so the GMK LGM can have a nice GUI and all that hardware acceleration and other goodies. Do you get that? I am laying out my development plans so there will be no version left behind.

Now, my other concern, is how shitty they are making GameMaker, I am really really starting to feel it's time ENIGMA not focus so much on compatibility and just do things our own way. There are a number of things that could just be done better in ENIGMA, and we should just say fuck compatibility already, we'd be able to do such a better job of popularizing the software, the whole clone ripoff thing just leads to comparisons and people always saying what we do and don't have. Where we could basically just do things a 1000 times better with much better design for shit.

1 would it be possible to simply do a version check before using the functions? We used to do this for some of the more advanced swing features and it worked great. This way you can maintain java6 support without incurring a big dependency, and display a warning of reduced functionality to encourage people to either update or download a jar.
2 if it can't be done directly in lgm, maybe a plugin could pull it off.

I never thought of that, but really it won't even be an issue, after Java 8 comes out, Java 6 will be dead in a matter of months.

3 why are we dropping gmk support? The reader and writer work great and it's the latest version gm people can use without switching to studio. And what about gm6?

I figured you wouldn't like that, but I mean of course when and if it became absolutely necessary. There are many things different, the extensions and includes are no longer a part of GGS but now their own resources. Sirmxe keeps saying I have too holistic of a world view as well. I can't help but feel I am making LGM worse by improving GMX support. When in reality the last version you worked on was the best version for GMK support.

So basically, what I am contemplating is getting everything as good as possible during 1.8.4 and then splitting LGM into a JavaFX rewrite with only focus on GMX. YoYoGames is doing major compatibility breaking changes such as requiring all games to utilize surfaces now and stuff, and people are raving it on. I am starting to feel the GMK version of LGM should stay where it is, and the program go in two different directions. Too much of what Studio is doing sucks now, and makes it impossible for people on even Windows Vista (polygonz) to run the software. I feel it is time ENIGMA and LGM and Studio go their separate ways.

I am more likely to wait until Java 8's release next month to get started though, because then I can basically branch all of LGM and redo it's interface as well.

Did some testing with the Scene Builder too, it's basically just like every other GUI builder, creates XML, but this would mean LGM by default would have only 1 look and feel that is the same on all operating systems, and you'd have to add your own through the use of cascading style sheets. Everything looks much better than Swing though, for sure.


A good candidate would could this LateralGM being released maybe LGM 1.8.5 or 1.8.6 in a few months time, and I would probably drop GMK support as well, since LGM 1.8.4 will offer the best GMK<->GMX<->EGM conversion.

I ran onto that a while ago! I love seeing all these new indie game engines popping up with a new alternative to indie design, different from GM which has dominated for too long imo.

So part of what I am doing in LGM 1.8.4 is addressing some long standing issues. One of these is the sound editor does not let you preview play MP3, MPEG, PCM, or OGG audio. One way to address this is the use of JavaFX which is now a part of the JSE since Java 7, though a substantial amount of the Java usage share is still Java 6.

I will probably end up doing which ever is the most popular. Also keep in mind that JavaFX also replaces swing for GUI controls allowing CSS for styling and theming, among a host of other features including hard accelerated painting and 3D graphics. Java 8 is mainly continuous integration with JavaFX and Oracle plans Java 9 in 2016 to be tightly knit with JavaFX, making it basically part of the core framework.

https://en.wikipedia.org/wiki/Java_version_history#Java_SE_8

But the point is these are supposed to be audio bit rates, I don't think these are all technically usable.
https://en.wikipedia.org/wiki/Bit_rate

Those are the only ones Studio lets you select, that's what those original numbers were.

I see that your code is working correctly though considering the original rules I gave.

Wait, shit, it's still not giving me exactly the correct numbers.

Code (Java) Select Expand


for (int i = 8; i <= 512; i += 8 * Math.floor(Math.log(i)/Math.log(8))) {
Debug.getInstance("").println(Integer.toString(i));
  bitOptions.add(Integer.toString(i));
}


: 8 16 24 32 40 48 56 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512

160-176 is supposed to be 160-192

Edit: don't I actually need an inverse log?

Fuck, the JVM is crapping out when i is 0.

: 0
: -2147483648
: 0
: -2147483648
: 0
: -2147483648
: 0

Edit: I see your update, actually, the numbers start at 8 so if I just set i = 8; it's all good and gives me the correct numbers! Thank you Harri!

Can someone help me with something?

I need to generate the following numbers in a combobox, so I don't have to type them out statically.

Code (cpp) Select Expand


8, 16, 24, 32
40, 48, 56, 64
80, 96, 112, 128
144, 160, 192, 224,
256, 320, 512


If you notice there is a pattern, every even square of 8 the increment increases by 8. For instance, the numbers increase by 8 up until it hits 64, which is a perfect square of 8, and then it starts adding 16, it continues this pattern.

Just added information is that this is for the audio bit depth in the new sound editor for LGM 1.8.4

Anyway, I wrote the following for loop.

Code (Java) Select Expand


for (int i = 0; i <= 512; i += 8 * Math.sqrt(i)) {
  bitOptions.add(Integer.toString(i));
}


However I only need to increment i by the multiplicative of the lowest square root, so if for instance i is 0 or 8, I need the result to be 1, but when it is 64 I need the result to be 2 * 8. Got any ideas?

I use CodeXL by AMD. It's basically the gDEbugger I used previously, but this one is a lot newer and is still maintained. And it works on all cards, not just AMD. OpenCL debugging works only with AMD in that tool. And that tool showed that many one vertex buffers have been created.

Ok then you can't roll out that I made a mistake in the vertex data upload, where the BufferData() shit occurs, I remember not getting any performance difference when I added flags for static and dynamic buffer usage, which was rather odd in and of itself.