ENIGMA Forums
Contributing to ENIGMA => Developing ENIGMA => Topic started by: Goombert on June 20, 2014, 03:00:37 pm
-
So I decided to do some testing and get the command line interface I started working and building an empty game. The program I have dubbed "emake" boots in less than 3 seconds initializing the library and all, and can compile and run an empty game in about the same amount of time. It is significantly faster than loading the IDE and building an empty game from there.
This has a lot of implications, you can build games without an IDE, you can build games much quicker, especially extremely large games like TKG makes. This also means we could significantly improve the performance of LGM working with large projects. This would be done by only loading the resource tree at startup, and loading and unloading resources or as you edit them or we could also just cache them.
This would allow someone like TKG to load a 100mb game much quicker, probably about 5-10 seconds, and build the game much quicker. The way we would accomplish building the game without loading it is by simply passing the file path of the project to the CLI and telling it to build the project.
A lot of these ideas are already utilized by Studio and it has many of the same restrictions that follow which are actually the same for most other IDE's. But we have some issues:
1) LGM does not have a guaranteed format, it lets you save and load from all formats.
2) This would require that you create the project directory when you want to make a new game, like in Studio, you couldn't get away with adding resources and saving later because the IDE has to have it on disk.
3) GMK is damn near impossible to optimize as a result of it being one giant ass file, you can't easily skip through parts of it and write a single resource.
4) You probably would not be able to build without saving your changes. I believe Studio has this same restriction.
Some possible solutions are the following:
1) Treat formats like GMK as an import/export where you can import a GMK but it will automatically be converted to GMX or EGM whichever format you choose.
Here are some benefits:
1) Faster loading times
2) Faster compile times
3) Less out of memory errors
4) Can build projects without an IDE
5) Makes it much easier for 3rd parties to write IDE's and other interfaces for the program
So the question is, does the cost outweigh the benefit? I am fairly certain most of you would say yes, but feel free to express your ideas on the matter.
*** Update ***
See latest forum post, the CLI now builds projects.
-
I would have to see it and try it !
I don't like the idea of discontinuing the IDE and building everything from a command-line. How the hell does that speed of development ? It only increases its time. Might be faster loading / compiling, but an IDE is a major time saver. How the hell would one place their tiles, objects, sprites in the room, without a room editor. You would have to create the instances yourself and constantly try and edit to get the proper X /Y. What about certain object properties that you control in the IDE, room, etc. in the IDE you have to select events and put code in it, how the hell are you going to do that without an IDE ? It's more time consuming and complicated. If YoYoGames decided tomorrow to discontinue its IDE and ask everyone to build their games using a CLI, no GUI/IDE, I'm quite sure even the experienced advanced developers would not be too happy.
The way I would handle large ass projects is by using external resource handling. I already have plans to make my own function libraries to handle this. I could make multi gigabyte projects and my EGM would load instantly since everything would be handled by the library and only loaded as needed, dynamically. But at least there is an IDE to work with to organise your resources / placeholders, edit room and other minimal stuff you would keep inside your EGM.
-
Judging your comments indicates you didn't even bother to read my post. Currently LGM loads your entire project into memory as one giant ass binary and then uses JNA to send that memory to the compiler, which requires changing endianess and is extremely slow as hell. The IDE could use the CLI interface and just pass the file to it to compile, is the whole point of this. To speed up the IDE, not make it slower.
-
Judging your comments indicates you didn't even bother to read my post. Currently LGM loads your entire project into memory as one giant ass binary and then uses JNA to send that memory to the compiler, which requires changing endianess and is extremely slow as hell. The IDE could use the CLI interface and just pass the file to it to compile, is the whole point of this. To speed up the IDE, not make it slower.
#1) I did read your post, what caught my attention is you mentioning that one could create an entire project without an IDE, which is was hard for me to digest.
#2) using the CLI through the IDE means having to save each time a change is made.
This increases the likelihood of LGM crashing. As I get cannot create new thread and many errors when saving too frequently in LGM, and yes even with empty projects that have no sprites or any resources loaded.
So this would mean each time you want to run your game you would have to save changes. But what if you DON'T want to save changes and only save them if the result of your test is productive, you would have to "undo" the changes yourself and re-save, OR you would have to save to a different file.
Personally I could live with that if the pros outweigh the cons, that's how it works in studio anyway, if it means it makes LGM more stable it would be good, which won't be the case since the stability issues are regardless of project size as I've proven many times
Regarding the building an entire project without an IDE particularly large one that part I am not convinced at all unless you have an amazing photographic memory and can visualise a virutal room editor and automatically figure out all the X/ Y's and object properties mentally ! lol.
-
No, it would actually make that a lot better, LGM crashes from saving frequently because it's accumulating more and more memory usage. Although you seem to be having other issues as well like bugs in JoshEdit, which aren't out of memory errors at all and make no sense.
Anyway TKG is one person who really wants it and so do I. And having it is better than not having it. This is literally the way practically all game engines and IDE's work. I can make the thing first and yall can decide later whether you want LGM to continue being a laggy Java program or you want it sped up.
On top of that, this lays the groundwork for a C++ IDE by getting a lot of the plugin redone in C.
-
No, it would actually make that a lot better, LGM crashes from saving frequently because it's accumulating more and more memory usage. Although you seem to be having other issues as well like bugs in JoshEdit, which aren't out of memory errors at all and make no sense.
Anyway TKG is one person who really wants it and so do I. And having it is better than not having it. This is literally the way practically all game engines and IDE's work. I can make the thing first and yall can decide later whether you want LGM to continue being a laggy Java program or you want it sped up.
On top of that, this lays the groundwork for a C++ IDE by getting a lot of the plugin redone in C.
So TKG making an entire game entirely from non IDE, I would be shocked. I'd love to know how he will do this, given his games are big is he going to place all those resources by mentally calculating their X Y coordinates ? How can you build a game entirely from CLI, you are not very convincing in selling this, since you are asking people's opinion.......
Ok you mentioned IDE accessing the CLI.
But you also mentioned that one could make an entire game without even using IDE....This is the part that I'd love to know about, how ??!?!? because I'd love to try that but can't see how I could possibly do so without an IDE. Unless you are building projects that don't involve a GUI :P
-
You wouldn't use the CLI to create the files, it's expected that the project will be created in an IDE. The command line will compile it. But yes it's possible to edit your resources outside the IDE using text editors and image editors, you can very easily open a sprite or background from a GMX and modify the resources, and you can open the object files and change the code and other properties. You can also edit scripts using notepad++ with the following extension.
http://enigma-dev.org/docs/Wiki/Plugins
-
No, it would actually make that a lot better, LGM crashes from saving frequently because it's accumulating more and more memory usage. Although you seem to be having other issues as well like bugs in JoshEdit, which aren't out of memory errors at all and make no sense.
Anyway TKG is one person who really wants it and so do I. And having it is better than not having it. This is literally the way practically all game engines and IDE's work. I can make the thing first and yall can decide later whether you want LGM to continue being a laggy Java program or you want it sped up.
On top of that, this lays the groundwork for a C++ IDE by getting a lot of the plugin redone in C.
Just that is enough of a selling point to outweight the possible cons, In my view and humble opinion if you're going to develop something as memory hungry as a video game editor (what with ogl openal, shaders, physics et all), you are better served doing it in a compiled language.
Anybody that has tried Eclipse knows just how memory hungry a complex application developed in java truly is.
-
Really the editor shouldn't be that memory hungry just because it's a game editor, especially when it doesn't run the game itself within the IDE.
But yes, moving more of the plugin's functionality to C++ is fantastic.
-
You wouldn't use the CLI to create the files, it's expected that the project will be created in an IDE. The command line will compile it.
So the IDE would simply call the CLI which will work directly on the file instead of the IDE passing its memory to the compiler, got it, that's how it should be done anyway, :D
But yes it's possible to edit your resources outside the IDE using text editors and image editors, you can very easily open a sprite or background from a GMX and modify the resources, and you can open the object files and change the code and other properties.
Agreed, but you still need an IDE to create that GMX, GMK, EGM or whatever .... That is my point, how would you otherwise build entirely from command line. I think I might actually do straight building from CLI for my upcoming dynamic / external resource handling library, I won't need sprites or placing stuff in room. With this new library I want to build, that will allow working on massive projects multi gigabytes in size even, and keeping the IDE un cluttered with only the code.
The faster compiling through IDE -> CLI is a much welcomed feature although on my system things compile quite fast - that might benefit those with slower HDDs ? systems ?
and if the only con is having to save changes before compiling, that is really not a con because this is how it's done in studio :D
-
THIS IS SO WONDERFUL ROBERT! If we didn't live on the opposite coast of the US I'd totally go gay and fall in love with you. (Just an expression to make a point - you're such a great friend) :D :D :D
I'm so happy!! :D thank you!!
-
THIS IS SO WONDERFUL ROBERT! If we didn't live on the opposite coast of the US I'd totally go gay and fall in love with you. (Just an expression to make a point - you're such a great friend) :D :D :D
I'm so happy!! :D thank you!!
TMI ;D ;D ;D
I guess the best way is to try it and see how it works out. I think this feature might become useful for some libraries / scripts I want to write, not requiring IDE / room editing etc.
-
THIS IS SO WONDERFUL ROBERT! If we didn't live on the opposite coast of the US I'd totally go gay and fall in love with you. (Just an expression to make a point - you're such a really great friend) :D :D :D
I know I am, but also I got the basics laid out for loading GMX and I have it parsing the # of rooms and their captions. Just a bunch of copy and paste work to redo the LGM version. Other than that only fonts need worked out, I'll need to make LGM write font textures to the GMX format which requires writing them the way they do, which will need reformatted into our way. We use less variables to store glyphs than they do.
-
Just to update everyone on this, the CLI now builds Project Chaos, with a few minor glitches and kinks I still have to work out this should be able to compile most GMX games shortly. It is also builds the game in less than 6 seconds, loading times are trivial now.
This is the pull request where I am working, I will be asking for a merge once I clean it up some and work out some of the kinks.
https://github.com/enigma-dev/enigma-dev/pull/765
(http://i.imgur.com/6JZAdUR.png)
-
YAAAAAAASSAAAAAYYYYYYY!!!!!! THANK YOU! :D :D
http://www.youtube.com/watch?v=qOllBh1-DCs
-
Can't wait to try this one,
could you document what it does and what it does not YET compile, would be really nice.
So once this is finished you will plug this into LGM ?
How will it work will we still have the option of using the regular method passing the memory content to the compiler OR saving project then accessing the CLI ?
It would probably be best to make the CLI inside LGM optional until it is 100% fully compatible.
Faster compile and more stable that would be a major step up as LGM is crashing like crazy, and no not just JoshEdit but there is shite coming from different orifices each time, EGMLib, JVM, Out of Memory, Swing, and some weird shite I never heard of it's a pain in the arsehole !
-
Yes I have got the huge bulk of the work done now, over 1000 lines of C++. I have further documented my project on the Wiki adding a section for my project side by side with the Java CLI that none of you even knew existed.
http://enigma-dev.org/docs/Wiki/Command_line_interface#Native_Command_Line
As you can see in the following image, Project Chaos now builds perfectly, we just need to work out the kinks on the Wiki above.
(http://enigma-dev.org/docs/wiki/images/0/04/Nativecommandline.png)
I am not going to bother describing how to compile this thing yet, I will when it's fully completed. This will not be replacing LGM's plugin or anything anytime soon either, this is just there for your use, if you don't want to use it, don't use it. It's better to have one than not have one. We'll look at further integration down the road.
-
I don't like the idea of discontinuing the IDE and building everything from a command-line.
#1) I did read your post, what caught my attention is you mentioning that one could create an entire project without an IDE, which is was hard for me to digest.
So TKG making an entire game entirely from non IDE, I would be shocked. I'd love to know how he will do this, given his games are big is he going to place all those resources by mentally calculating their X Y coordinates ? How can you build a game entirely from CLI, you are not very convincing in selling this, since you are asking people's opinion.......
I love how Darkstar missed the point entirely - when he was notified of this, he was still missing the point for several posts more. :D I have noticed that the level of misunderstanding on this forum is unbelievable massive. It's like if we didn't know english and used google translate to talk to each other, even when many here have english as the first language.
1) LGM does not have a guaranteed format, it lets you save and load from all formats.
But should we support all formats in CLI? I think we should only support compiling from egm. If a person wants to use the CLI, he should convert to egm.
2) This would require that you create the project directory when you want to make a new game, like in Studio, you couldn't get away with adding resources and saving later because the IDE has to have it on disk.
Couldn't the IDE just save to temp folder whenever you press "Compile"? And save to the project file when pressing Save.
3) GMK is damn near impossible to optimize as a result of it being one giant ass file, you can't easily skip through parts of it and write a single resource.
I think we shouldn't be supporting it.
4) You probably would not be able to build without saving your changes. I believe Studio has this same restriction.
But what if you checked if the project is modified from what is loaded or not, and then save to temp folder with the changes if it is modified, or don't save it and just compile the project file if there are no changes? Easier way is to write out to temp folder whenever you press "Compile", but then it might be slightly slower (depending on how fast egm can be written).
1) Treat formats like GMK as an import/export where you can import a GMK but it will automatically be converted to GMX or EGM whichever format you choose.
Exactly, use EGM internally.
-
Harri is on a roll :D
I love how Darkstar missed the point entirely - when he was notified of this, he was still missing the point for several posts more. :D
What am I still missing ? LGM passes its memory to the compiler, where CLI would process the file directly no ? Not everyone has a clear understanding of the inner workings of ENIGMA or how IDE and compilers connect to one another..... :P It's mostly his comment building an entire game without the IDE,
On that note, I agree we should use EGM.
Also there is a flaw in LGM anyway, despite saving project before closing LGM it always keeps reminding me that I have not saved my changes and if I really want to quit. So that would need to be fixed first.
-
@Darkstar2 I'm using LGM as my IDE. I never said I would not use an IDE. If I were to not use LGM, which I am, I'd at least use GMS's IDE which is pretty damn close as I know what parts of LGM aren't supported in GM and vise-versa. Anyway, yes I'm using LGM, but since LGM is so buggy and slow with calling the compiler through the plugin (*cough* blame Java), the only thing I'll be using CLI for is testing and compiling projects exported from LGM.
-
Darkstar2, they mean how you take some trivial thing that I say and blow it into a giant elephant in the room, that somehow me making a CLI means the death of the IDE. Helen Keller didn't have enough tourettes to make such an illogical connection.
Anyway, Harri, LGM is not my project, it is IsmAvatar's and it is a GM IDE. Many people on the GMC are actually still using it to downgrade GMX into GMK and vice versa.
We could however fork LGM and make our own IDE out of it.
-
When I'm bored for an extended time period, I will try to port an existing GMS game of mine to work in GM 8.1 . I did it successfully with my blockhead game. It was cool to see it happen, but it was a complete waste of time I don't know why I did that or why anyone else should, especially with GMS standard now free. Doing this for removing the splash screen makes sense, I guess, but using GMK to port to Mac easy and cheap with GM4Mac is a more worth while use if you can't drop $100 to create for Mac. When I get a Mac desktop I'm buying GM4Mac just so I can do all my serious development on Mac as I'd strongly prefer.
-
When is the first complete/stable release most likely gonna be ready? :D
-
Probably two weeks, but I have 2 new classes added onto my schedule, 1 just ended, and the other ends in 2 weeks, so let's shoot for 4 weeks for it to be able to build one of your games.
-
Darkstar2, they mean how you take some trivial thing that I say and blow it into a giant elephant in the room, that somehow me making a CLI means the death of the IDE. Helen Keller didn't have enough tourettes to make such an illogical connection.
LOL! Whatever, I am used to breaking world records anyway. I knew what you meant shortly after what threw me at first is you saying one could build from scratch without the IDE.
What I am still confused about is how did people use ENIGMA before LGM ? How do you build a game without the IDE....
-
@Robert high five broha
-
Darkstar2, that's actually an interesting question, I wasn't here when they started the project but LGM and ENIGMA were developed concurrently and then merged. But ENIGMA did have a short time without an IDE, I wonder what it was like back then?
TKG, I hear yah niggah.
-
Darkstar2, that's actually an interesting question, I wasn't here when they started the project but LGM and ENIGMA were developed concurrently and then merged. But ENIGMA did have a short time without an IDE, I wonder what it was like back then?
Probably people manually created the individual files themselves, for objects, rooms, etc...You could if you wanted to make a console IDE, using ANSI for the GUI stuff lol.....probably would be a lot more stable too and low memory consumption that would go well with the CLI.and easier to integrate....could write that one in QB45 ;D ;D ;D
-
Actually I would prefer a game engine that doesn't require an IDE. I like to do scripting in Notepad++ or other. Having map/room editors is good as well. This is why I believe in game engines fit for a particular purpose. The very reason I would never use Unity3D for a serious game is that it's just too much bloat.
If I were to write a cross-platform game, I would probably just use Irrlicht and some model editors, make my own map editor. GM's framework despite the negative opinions, has always been very lightweight, some of my various complaints are them bloating it with API's that not everyone needs. If I ever used Studio or ENIGMA, I would probably use one of the physics extensions and not the one built into the program, mainly because it's shit.
But that's for another topic, so please, get back on topic, or start a new one to discuss those matters.
-
Josh can probably give more details here, but IIRC the time before LGM there wasn't really an easy way to build projects. There wouldn't have been much use in having one anyway, considering how little was implemented. Mostly it was engine and parser work.
-
1) Faster loading times
I've seen that when a project is loaded, there is a lot of events which are fired and i am not sure they are all needed at this time. For example, the updated event in the ResNode is fired each time a resource is added. I wonder if some optimization could be done on this (for example disabling some listeners when loading the project or adding them when the project is loaded) and could help the loading time.
-
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/768
(http://i.imgur.com/CMrXnmN.jpg)(http://i.imgur.com/F8Y4njD.png)
Project 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.
-
LOL - why is TKG's intro flipped upsidedown ????
-
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.
-
Just got back from a 4 day vacation in the blue ridge. First thing I see when I get home is the notification of this due to WiFi. Robert you are the bomb. But better! The bomb.com! I'm really loving where ENIGMA is going. This CLI of yours will make creating your own ENIGMA / GM IDE easier than ever on Windows and Linux. That's a beautiful thing. That's not what I'm using it for. I'm just using this to bypass the limitations of Java but yeah I'm sure there's plenty more benefits behind this work. Thank you Robert!! :D
-
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.
-
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.
-
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.
-
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 :D
-
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.
-
Still not a reason, it's not as if that was a hog, so they automatically take decisions for people and assume people will use PNG, and convert everything to it. :D
-
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.
-
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.
-
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.
-
Wikipedia has the full BMP spec.
http://en.wikipedia.org/wiki/BMP_file_format#Pixel_format
And GM never had the ability to do it at runtime, but it's possible in Direct3D and OpenGL even with the ffp, but if you want it you're better off writing a shader for it.
http://www.opengl.org/discussion_boards/showthread.php/175741-Colour-Threshold-Alpha
-
Runtime probably isn't the correct word for what I meant. It's only transparent after the exe is compiled and run. If you try to save that BMP as a BMP file and not a BMP used in a exe, yeah there won't be transparency. Applications can hack the appearances of a BMP like replacing a color with transparency but good luck trying to make BMP do that in windows photo viewer. I don't know if we are misunderstanding each other or I've missed something important in my years as a computer geek I have no idea.
-
Yes, then maybe I am not understanding.
* You can make a BMP, PNG, or JPEG have a transparency pixel, that works for all formats.
* You can remove the transparency pixel when you load, or using a shader and do it every frame. If the former and you go to save a background or sprite, the image will be saved with the transparency removed.
* Bitmaps can be 8 (monochrome), 16, 24, and 32 bits
-
Robert, I already explained this, I know JPG can have a transparency pixel. But JPG is a lossy format. Meaning I could make a sprite with a blank white background for where I'd like it to be transparent, but when I save the JPG from MSPaint or whatever image editor there will be a slight value/color variation in that white area so when I tick the "transparency pixel" box it will only make transparent a rough portion of the initial area one would want to be transparent.
I think we are still not on the same page so I guess from here on out I'll be more on-topic in this thread.
-
I know what TKG means, unless you NEED more than 256 colours for your sprites in such case you would use GIF instead, which is more suited for sprites than JPG anyway. But anyhow with PNG I guess all that is moot, I use PNG all the time now. Only thing missing in LGM is automatic support for APNG, directly
loading APNGs.
-
Will there be a Linux port of emake? Please... Or is there one?
-
He is developing it on Windows, bgordebak.
-
It should honestly take very little effort to compile the thing on Linux. Some of the code I started with was taken from wxENIGMA which Josh helped me write.