Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Goombert

Off-Topic / Re: I'm officially not . . .
« on: September 23, 2014, 06:59:51 pm »
I just want to let you know ed that you should take nothing for granted and don't let higher edumucation go to your head.

Ideas and Design / Re: In need of a Sonic fangame engine for Enigma
« on: September 23, 2014, 05:16:35 pm »
The Bad
A major problem with all of these is that every one would require a lot of recoding to even work in Studio because of their reliance on the deprecated variable maps and dynamic execution/reflection. We do intend to add support for these features, but I am thinking about taking the time some day and adding the variable maps (variable_local_get/set) and adding a compatibility setting but I think Josh would probably prefer I hold off on that so I am not sure. In fact I have faith that if someone took the time to implement the functions the Sonic SRU engine would work, it only uses them to lookup the animations by name, this is one of the things I hate about how people used the variable maps, too lazy to write their own maps with data structures.

The Mundane
I want to assist you with this HitCoder so while waiting for TKG to respond to me I decided to do some more digging.

First you guys missed a couple of other engines out there.
Sonic Geneis/Advance Engine originally in GM6 and also repurposed:
Sonic Rex Engine:
Super Sonic SRU Tutorial:

There is also the following blog I found which describes some of the math involved in making a Sonic engine with GM.
There is also the Sonic Physics Guide.
And here is a whole list of resources about Sonic games in GM.

The Good
The following tutorial works perfectly. Just rename the room when you download it because it has illegal tokens.

This tutorial is the same as the one before, just rename the room and it should run.

I'll post back with more later.

Go ahead and send me the file in a PM TKG, this is partially related to me scaling the views to emulate application_surface. Should all be very easy to fix.

But first Problem #4 is not actually a problem, heh. This is the way GM8 behaved, during what you call the black screen this is the initialization period where the loading bar is shown, since we don't have a loading bar this is the period at which Studio shows a splash screen which I was intending to implement. Nothing actually changed in my recent commit is what I want to point out to you I in fact partially corrected this behavior because we do not make the window visible until the graphics context is created and then we load.

The initialize_everything() call after that is where loading occurs, this is why the window is black during this point in time. What needs to happen I believe is that EnableDrawing() should render the splash screen.

Problem #5 is basically the same as the views, I just need to tweak some variables.

And #3 I will simply have to investigate, I know we block the caption from changing if it does not actually change but I don't know what is wrong I will have to see the project to determine.

Additionally for #1 and #2 it would help to see the Studio and or GM8 equivalent screen shot, just so I know for sure how it is supposed to scale. Also it is important to remember that for issues such as these it is better to make small individual test cases that reproduce the issues, I hate having to fix bugs in large games it becomes very time consuming.

General ENIGMA / New Portable
« on: September 23, 2014, 01:25:52 pm »
I just want to let everyone know that after extensive testing several new improvements and general cleanup has been included in a new release of the Portable ZIP. Some such changes include typo fixes, missing XLIB functions, inconsistencies, and many other changes including the introduction of scaling options for XLIB.

You can get the new Portable from the downloads page.

You can as always manually update the jars and pull the changes yourself.

Finished Games / Re: Window Styler, Web Browser, and Embed Program
« on: September 22, 2014, 08:46:11 pm »
This is excellent news TKG! I want to note though that for ENIGMA compatibility you may need to download the recent window fixes using git fetch and git pull from the git-bash program in the ZIP. I will include these changes in a future ZIP release but I am currently busy improving XLIB.

Issues Help Desk / Re: window_handle() is messed up
« on: September 21, 2014, 11:47:10 pm »
That's actually not a regression sorlok, we now like Studio and GM8.1< create the backbuffer for the whole window, since well we only have 1 window. So we have to clear the window when it is resized with the window color, and we also need the native implementation for window color so that it shows while resizing the window. You just have to copy it to the graphics bridges for Cocoa, I can't test so that is why I haven't.

Issues Help Desk / Re: window_handle() is messed up
« on: September 21, 2014, 08:57:09 pm »
Alright everyone sorlok offered some testing for other platforms and I have decided to merge the pull request. Please fetch the changes and test them TKG and everyone!

Developing ENIGMA / Re: Change
« on: September 21, 2014, 07:01:23 pm »
Iji should be built and I'll leave that to sorlok.

Josh you could build Project Mario for me as it uses inheritance. I have massive changes going on here that I need to test as well and I cba atm.

But also I would like to refute what Harri has said, the code has gotten a lot cleaner in a lot of ways directly related to me, such as the introduction of general headers we lost a lot of unnecessary duplicate code. A good example is that a lot of general drawing functions are written using the GML functions, which is obviously easier to understand and change ever for novices and that was one of my arguing factors in doing so. screen_redraw was one getting pretty bad though until Josh cleaned it up a bit. But I will say audio is a complete fucking mess, and that is not so much the fault of the inexperienced first time contributor that I was when I got here than it is YYG's constant implementation and deprecation of audio_* functions it's impossible to pick a version of their shit and implement it and expect it not to change. While additionally also having to retain all of the original sound_* functions our audio system is a mess.

Developing ENIGMA / Re: EGM Migration
« on: September 21, 2014, 06:50:52 pm »
That sounds fine Josh I would welcome your changes!

Off-Topic / Re: I'm officially not . . .
« on: September 19, 2014, 10:18:23 pm »
Congratulations edsquare! I'd like you to know you have my support! (Y)

Off-Topic / Re: 2.5 billion for an indie game
« on: September 19, 2014, 10:16:54 pm »
Ha Josh <3

Works in Progress / Re: Iji is now in Beta! Please test~
« on: September 19, 2014, 03:21:24 pm »
Hello sorlok I wanted to let you know that I tested your latest build and fullscreen and the various scaling does work for me on Windows. However I want to let you know that I making changes to remove the child window from win32 which you are already aware of, I believe my pull request may soon begin conflicting with recent changes you have made but fear not as I am being very thorough and will be testing Linux as well. The only place I will not be able to test is Mac.

Issues Help Desk / Re: window_handle() is messed up
« on: September 19, 2014, 03:09:38 pm »
Ok well I've got nothing but good news, the implementation is working great and fixes numerous bugs.

Some of our basic window functions were also break, for instance window_get_width() was reporting the minimized window size when in fullscreen. I have to run through and fix a lot of this for XLIB as well. All the scaling is now implemented through our viewports.

Proposals / Re: "Completed Games" forum
« on: September 18, 2014, 07:59:34 pm »
I agree.

Issues Help Desk / Re: window_handle() is messed up
« on: September 16, 2014, 10:17:26 pm »
Guys let's not overtrivialize this, it takes about an hour of work to fix this I just don't have the time right at the moment. Clearly we should not be using two windows, when the child window is removed all games will behave as if the scaling option is set to "Full Scale". Then we reimplement the options with application_surface and provide an option to completely disable generation of application_surface altogether, and in the event of the hardware not supporting surfaces it will resort to "Full Scale" mode and leave a message in the debug log. First I must test though if the "Full Scale" option in Studio does still generate the application_surface or not, correct me if I am wrong but I believe it always does, though in ENIGMA I may just make that point to the default framebuffer since with "Full Scale" mode there is no real need to generate a surface you already have that behavior with the default framebuffer.