|
Goombert
|
|
Reply #31 Posted on: July 01, 2014, 03:43:30 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
ego, the idea is we only parse the tree of a GMX or EGM and only load resources as the user requests and edits them, we don't actually need to load any of the resources until you click on one. Know what I mean? But the only problem there is that we can't do that with GMK, so we'd have to force people to convert to another format or drop GMK support. The project would also need to exist on disk, this is again how Studio's IDE and every IDE on the planet works. That's the most important way to look at it. But regardless, that doesn't mean we can't optimize what we currently have in other ways. Anyway, I have basically finished the main part of the GMX reading for the CLI interface, Attack of the Naked Block Heads and the FPS example both build now. Ignore what appears to be a lack of transparency in the FPS example though because GMX and Studio deprecated that setting altogether. Read the pull request for more details. https://github.com/enigma-dev/enigma-dev/pull/768Project Mario can also be built with the command line. Tomorrow or the next day I will look at building this for Linux and then give you all some instructions. This thing is still not officially complete, fonts wont work until I figure out how to convert them and make LGM write out the textures or discuss it with Josh further, and there's other shit, like how to specify ENIGMA settings and flags for emake, etc.
|
|
« Last Edit: February 17, 2021, 05:21:18 pm by Goombert »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
Goombert
|
|
Reply #33 Posted on: July 03, 2014, 03:49:36 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Surfaces issue in GL, they are currently flipped upside down, we haven't figured out the best solution yet but the discussion was mainly between Josh and Harri. I think we should go back and fix them in GL1 the slow way though, since GL1 is simply intended to work, GL3 can figure out a better solution than scaling.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
Goombert
|
|
Reply #35 Posted on: July 04, 2014, 02:38:19 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Yes exactly TKG, now you can simply pass a file path to it and it can build your game.
I have fixed most parenting and postponed references issues, as well as drag and drop parsing, though there are still a few issues. The biggest now is fonts, I haven't written a converted which chops up their font texture and dices it into ENIGMA glyphs nor have I made LGM write the font texture to GMX yet. And I also have not included a default font, I will discuss this with Josh so we can outline a way of including default resources with ENIGMA. So atm, don't expect any text rendering!
That said, your game crashed after skipping the intro screen, but this may have been due to me testing it prematurely, I did not test it again after completely fixing drag and drop and building the FPS example where DND was also causing other crashes. So it may and may not crash again if you were to build it I have no tested yet.
My biggest concern is all the fucking JDI output, it took 30 seconds to build the game, but it could have done it in half the time if JDI wasn't printing 1.24 GB's of bullshit.
Now I do not officially support building this CLI yet, however I will give instructions who anyway that wants to take a wild canoe ride down that shit creek. Also I have not tested it on Linux yet at all, so don't expect it to work there yet. 1) Open git-bash 2) 'cd enigma-dev/CompilerLine/programs/emake' 3) 'make' 4) 'cd ..' 5) 'emake.exe'
Emake requires a specific working directory so please make sure you open git-bash and cd to the right location even after building it, you will not need to call make again unless you make changes to the source so you can subsequently just cd to programs and run it. It should then boot up the compileEGMf and hook up the compiler then ask you what you want to do. Here are some of the current commands. quit : sends shutdown signal and closes the program gmx : will ask you to specify the GMX path and the exe location of the output executable, must include file extensions and be absolute paths test: builds an empty game
Now because I do not have it cleaning up its own memory yet either because we need to outline the commands and flags that this program will have you will need to quit and restart the program for each subsequent build until I can discuss this further with you guys and Josh to see how we want this thing to officially operate.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
time-killer-games
|
|
Reply #36 Posted on: July 04, 2014, 12:55:25 pm |
|
|
"Guest"
|
I personally don't care about supporting GMK formats anytime soon but once you've completed the GMX, EGM which is the most stable might be a good idea. GMX is good enough as most of my games I'm importing directly from studio, but I'm just throwing this out as I know most of you guys really prefer EGM anyway.
My last suggestion being by the time we support multiple input formats they should be detected by the file extension automatically, instead of using a different input flag. Instead of calling the flag "GMX" it could be "input [*.egm|*.gmx|*.gm81|*.gmk {8}|*.gmk {7}|*.gm6|*.gmd {5}|*.gmd {4}|*.gmf|*.gme]" Please note nearly all the formats I listed were high-pathetically speaking. I'm not 100% how this should work.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #37 Posted on: July 04, 2014, 02:59:13 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
The reason EGM now has superiority for ENIGMA is because ENIGMA still has things like corner transparency that Studio does not. GMX completely removes the option from the format, and ENIGMA incorporates all GM versions.
Supporting EGM is also impossible until we hook up this CLI to read drag and drop action libraries, GMK and GMX store the action data not just by id and subid but they also store applies to and everything so that you can format it out into code.
DND -> GML converters are extremely easy, LGM and the CLI in fact convert the entire event action block to EDL in just 25 lines or so.
Also some commands and flags will be optional, so there will be a flag that tells you the format of the file, and I guess the default will be if you don't specify a format to grab it from the filename.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Darkstar2
|
|
Reply #38 Posted on: July 04, 2014, 06:16:12 pm |
|
|
Joined: Jan 2014
Posts: 1238
|
Of all the shite they deprecated what's the reason behind removing the corner transparency Why not simply ask the user to select / configure the transparent area ? ASSUMING a corner pixel is highly retarded, what if I want another area to be transparent. There are far more reasons why it is good to use EGM far more than just the corner pixel thing
|
|
|
Logged
|
|
|
|
time-killer-games
|
|
Reply #39 Posted on: July 04, 2014, 11:54:48 pm |
|
|
"Guest"
|
The need to have a corner transparent check box ever since GM 8.0 has been permanently blotted out due to the fact it's useless now with built-in PNG support. The only reason 7.0 and older have that check box is because they use BMP and BMP doesn't support transparency on it's own.
|
|
|
Logged
|
|
|
|
|
time-killer-games
|
|
Reply #41 Posted on: July 05, 2014, 02:05:05 am |
|
|
"Guest"
|
BMP isn't as good it has no alpha. Even with a transparency corner. Last I checked when it comes to file sizes BMP aren't much different. JPG look like shit and can't have transparency even with a transparency corner, because the lossy quality will prevent a good portion of the image that should be transparent to not be transparent as the color used in that corner is based on that one exact RGB/HSV. GIF might work but the quality will in almost every case be down-right horrible.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #42 Posted on: July 05, 2014, 12:39:19 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Uh, yeah, no TKG. 32 bit bitmaps do store transparency, a bmp is just a raw uncompressed lossless dump of pixel data.
That corner transparency option was good for all image formats, because it doesn't actually remove the background color until startup but once it does it does it for the entirety of the execution, which is more optimal than using a shader to do it every frame.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
time-killer-games
|
|
Reply #43 Posted on: July 05, 2014, 01:16:38 pm |
|
|
"Guest"
|
That's strange, I've never seen a single BMP with transparency or alpha on it's own in my life. I have seen ways to make them transparent programattically within applications at runtime (like what that check box in GM7 did), but I've never opened one in the browser or photo viewer that has it's own transparency/alpha by itself. This is new news to me.
|
|
|
Logged
|
|
|
|
|
|