41 replies to this topic

[jakman4242]

So, after reading what Yourself said, and thinking realistically. Couldn't you make a script to save an image as a different file type than a .bmp? Well, and have the file format be correct, instead of just a false add-on of a file type.

[molloyboy08]

Thank you Yourself for explaining that so well. It was exactly as I was thinking but why is it that I never speak so precisely.... As the the data type thing I can't beleive I didn't see that and I never noticed Yourselfs sig, pretty nice.

Anyway. You could do that but it doesn't mean you should. 1) the script would be long 2) the script would be slow, 3) it would have to be hardcoded to actually encrypt the data too. A dll would be a more practical choice.

[Yourself]

So, after reading what Yourself said, and thinking realistically. Couldn't you make a script to save an image as a different file type than a .bmp? Well, and have the file format be correct, instead of just a false add-on of a file type.

Yes. Every file format is accessible, but don't take that to mean that it's practical. Many file formats are pretty well documented. Back when the binary file functions were added I created a little application to make GM compatible .ico files. If you bothered to learn the formats, you could even output video from your game although that would be completely impractical.

[johnie102]

binary is a data type

No it isn't.

Oops, you probably won't believe me, but I didn't meant to write that. I meant to write that binary is a numerical system (I really hope that that is the right word for what I meant, else I'm gonna do a facedesk). Anyway, as I said you are way better at explaining stuff like this than me.

Edited by johnie102, 17 August 2008 - 09:57 PM.

[jakman4242]

So, after reading what Yourself said, and thinking realistically. Couldn't you make a script to save an image as a different file type than a .bmp? Well, and have the file format be correct, instead of just a false add-on of a file type.

Yes. Every file format is accessible, but don't take that to mean that it's practical. Many file formats are pretty well documented. Back when the binary file functions were added I created a little application to make GM compatible .ico files. If you bothered to learn the formats, you could even output video from your game although that would be completely impractical.

I see. This just makes me realize how open and flexible computer programming is. I guess when you bring things down to minimal facts things start making sense. Maybe the use of the word minimal isn't a very good word for it, but it's the best I can think of right now. Also, how someone(I believe it was you, Yourself) stated it depends how binary is read by the computer on what it does. Well, that makes me thing. Wouldn't in the case of a compiled language, say C++, the compilers be in the place of the machine reading it, but instead of translating it into commands for the computer, it translates it to code that can be directly read by the computer. And the process being ever so complicated as you go up the scale of programming language types, as GML is translated, and goes through several processes to get down to the directly readable code. This is correct, no?

[johnie102]

So, after reading what Yourself said, and thinking realistically. Couldn't you make a script to save an image as a different file type than a .bmp? Well, and have the file format be correct, instead of just a false add-on of a file type.

Yes. Every file format is accessible, but don't take that to mean that it's practical. Many file formats are pretty well documented. Back when the binary file functions were added I created a little application to make GM compatible .ico files. If you bothered to learn the formats, you could even output video from your game although that would be completely impractical.

I see. This just makes me realize how open and flexible computer programming is. I guess when you bring things down to minimal facts things start making sense. Maybe the use of the word minimal isn't a very good word for it, but it's the best I can think of right now. Also, how someone(I believe it was you, Yourself) stated it depends how binary is read by the computer on what it does. Well, that makes me thing. Wouldn't in the case of a compiled language, say C++, the compilers be in the place of the machine reading it, but instead of translating it into commands for the computer, it translates it to code that can be directly read by the computer. And the process being ever so complicated as you go up the scale of programming language types, as GML is translated, and goes through several processes to get down to the directly readable code. This is correct, no?

(disclaimer: I'm not an expert on this, but I'll try my best at explaining this, some things could be incorrect)
In the beginning, computer programs were written directly in machine code. But this was hard to learn, took a lot of time and was a horror to debug. So 'people' started developing what is called assembly language. This is (as far as I know) machine code, but then in more human terms (using words and such). This assembly language is then somehow (I don't know how exactly, but using a compiler) converted to machine code. In the beginning days of the compiler, compiling was inefficient and it was more efficient writing in machine code. But over the time compilers became more and more efficient and now it is probably more efficient writing assembly then machine code. Anyway, assembly still takes a lot of lines for doing what you want. So in the eighties (I think, could be seventies) people started developing higher level languages that eventually evolved in the likes of PASCAL, DELPHI, C and C++. These languages are first brought trough the assembler (they first go trough the linker, but this is irrelevant). This converts the language to assembly and then the assembly source goes trough the compiler which converts it to machine code.
Because the assemblers and compilers are so efficient you would be crazy developing stuff in assembly and such (or you need to really really have complete control over your code). There is no way to see what language you used if you see the assembly source. (although, I don't know why GM only accepts DLLs written in certain languages. This doesn't really make sense if you ask me, but oh well)

Now, on GML. GML is simply some ordered text that is read by the runner (which is written in DELPHI if I recall correctly) and every command in GML correspondents with a function (or more) in the runner. This process (checking GML and seeing with what function it belongs) is done in real-time. This is why GML is slower, but does allow for easy bug-tracking (you can see on exactly what line an error happened) and inserting code (execute_string/file()).
I hope that made sense.


Now a question for people smarter then me:
How possible would it be to convert the GML to actual DELPHI code on saving the executable. I understand that this way it would take much more time compiling your game, but it would result in a speed increase, right?

Edited by johnie102, 18 August 2008 - 09:31 AM.

[icuurd12b42]

snip

I suggest you consult wikepedia on
Machine Aode
Assembly Language
C++
Interpeted language...
second generation language

in short, machine code is a series of bytes... You can write a program with a hex editor it's the 1st generation language
assembly is a second gen language... Converting the bytes commands to readable few letter commands for editing, compiling the result to machine code.
c is 3rd gen, more readable
c++ 4th gen or 3rd gen, depending where you come from and philosophy can be used as a forth gen language from all the classes you have, but still 3rd gen
VB is 4th geneneration, hard to make an error, but could be consirered 3rd gen in todays description... Because it's use is not specific, appart from being a windows programming platform.
GML is 4rth Gen because it's specific to something... gaming
D&D could be considered 5fth gen, I guess, but it's more like visual 4rth gen

The evolution of the terminoly makes it hard to follow over time...

When I started,
1st gen meant machine code
2nd gen meant assembly
3rd gen mean c and other more readable code
4rth gen basically meant interpreters with a nice WYSIWYG interface

Each generation was used to make the next if you catch what I mean. That was the way we went at defining the generations. Looking at wiki right now, it's hard to tell what's what... It was easier back then.

Edited by icuurd12b42, 18 August 2008 - 10:23 AM.

[icuurd12b42]

Hey, is this compiled with debug information because is pretty darn big for what it does...

[ChIkEn AtE mY dOnUtS]

Hey, is this compiled with debug information because is pretty darn big for what it does...

No, its just that Dev-C++ wouldn't compile unless I included a crapton of libraries.

[jakman4242]

For the record, Pascal(Not PASCAL) is a language founded by the company Delphi.(again, not DELPHI.)

And it seems my half-question half philosophical assumption was never answered. Where is Yourself when you need him, to clear matter such as these up? Probably reading our posts and shaking his head a disgust.

[icuurd12b42]

Hey, is this compiled with debug information because is pretty darn big for what it does...

No, its just that Dev-C++ wouldn't compile unless I included a crapton of libraries.

Looks like it's craping out on loading a string... I don't get how you set it up because in the script, you are returning the result right from the dll. Have you figured how to create GM strings?

Usually, you have to mem copy to a gm allocated string in the dll

var str; str = string_repeat(chr(0),256)
numbytes = external_call(global.dll_ReadString,argument0, str, 256);
return string_copy(str,1,numbytes)

and in the dll you would memcpy, min (sizeinfile, bufsize) onto str

And, looking at the file, it looks like it did not save my string right if not at all.

Edited by icuurd12b42, 19 August 2008 - 09:19 AM.

[mrsmes]

excellent with super binary in GM, you could almost make a super OS, and a super computer with Game Maker, however the hardware would be all that needs designing...

[OniLink10]

It's a Great DLL, but it's rather slow.... Could you find a way to speed it up?

[them4n!ac]

no he can't
it's just an std::ifstream through a dll
if there would be some file loading scripts, that could bring more use to the dll

[ChIkEn AtE mY dOnUtS]

Its more like GM is slow, not my DLL.

[Skarik]

After reading Icuurd's posts, I think I'll stick with his binary DLL. The integrity of strings is very important to me.

[them4n!ac]

Its more like GM is slow, not my DLL.

It's more like you are slow to understand that wrapping small functions won't lead to anything good.

Edited by them4n!ac, 18 November 2008 - 12:27 PM.

[ChIkEn AtE mY dOnUtS]

Its more like GM is slow, not my DLL.

It's more like you are slow to understand that wrapping small functions won't lead to anything good.

This was created to be able to write in data types other than bytes. It also wasn't originally coded for game maker.

[posva]

this dll is a bit tooooo slow...

what a pity

[gmcsdobbie]

Link does not work.