game-editor.com

Hey, a friend of mine made his own programing language, Honestly I dont know how... But anyway he tought me it, and I'd like to share it with you guys Tell me what you think, I've commented the code so you can understand it a bit

Code: Select all

ALLA:: M-Trigger = E_1  /-Mouse Trigger for left click
ALLA:: M-Trigger = E_2  /-Mouse Trigger for right click
ALLA:: M-Trigger = E_3  /-Mouse Trigger for Middle click
ALLA:: M-Trigger = E_NULL  /-Mouse Trigger for other mouse buttons


ACCESS: sysOS /-Gain access to the OS file your editing, for example... MFI.dll
A-TYPE = ".dll"
A-NAME = "MFI"


int KEYTRIGGERS = ARRAY-(NULL); /-Access all of the keys on the keybored
int xMOUSE = DEFAULT /-Default settings for the mouse's x readings
int yMOUSE = DEFAULT /-Default settings for the mous's y readings

READ::TYPE = "Microsoft .NET framework 1.0" /-Enable usage of the .net framework by microsoft
READ::TYPE2 = TYPE + NULL /-Reads the first one and auto updates the latest framework

UPDATE::READ::TYPE = true /- On every frame update, it reads from the microsoft.net framework

RUNMEMORY = to.PROC(SMA=58238.120) /-Allocate half of your pocesses to the processor if the item being ran is above 120 MB



if (MEMSET::SMA>120)
{
   to.PROC(SMA) = true;
   else::to.PROC(SMA) = false;
   SendMSG(NewWindow(320, 180, "Your RAM was using over 120 MB\nWould you like to use your processor as RAM?", Btn("Yes"), Btn("No"));
   if (Btn.press == 0)
   {
      to.PROC(SMA) = true;
   }
   if (Btn.press == 1)
   {
      to.PROC(SMA) = false;
   }
}
loop(int x) when (x<4) DoNum(x += 1)
{
   SendMSG(CurWindow("x = " + x);
}


That's just for a small example

DSN means Digital System Networking. And using this, I was able to make my own OS based off of DOS... It's called "SkyOS"... I'm not sure if that name's taken but here is a few screenshots

The reason I'm sharing this is because well, if game editor could use it's own code instead of C, (Or atleast a programming language made in C++ to make things easier, and also more effective) it'd be allot better




However, I do have some errors in SkyOS... Such as some of the buttons being misplaced for some reason... idk why, and also sometimes when you hover over the X button, it for some reason vanishes :/


For now, SkyOS is going to be ran inside of windows, so an EXE will be here soon. Also I'm going to make a game editor version of skyos

Hblade wrote:The reason I'm sharing this is because well, if game editor could use it's own code instead of C, (Or atleast a programming language made in C++ to make things easier, and also more effective) it'd be allot better

I disagree here, C has a legacy and its uses are widespread across the word. The higher the level of the language the LESS efficent it becomes. Fact is, its much easier for newcomers whom can program in C to use GE (which is a fair amount), and if they don't, they can start learning a language that has gained wordwide acceptance by using GE. That's actually why I chose GE over other game engines; I didn't have to relearn an entirely new language specific to itself!

Still, seems like your friend develloped something pretty neat there. Did he write the compiler from scratch? Congradulate him for me if he did as that is one onerous task!

That's all for me, take care H.

Well he didnt do it alone. He had 2 or 3 (cant remember) friends help him out on it, but I never met them :/ Anyways it can be used for making an OS, as a matter of fact, I made my own DOS(sort of, atleast it looked like a DOS >.>) that way. Even though... it didnt run CRAP but heck atleast it was an OS

pyrometal wrote:I disagree here, C has a legacy and its uses are widespread across the word. The higher the level of the language the LESS efficent it becomes.

What a bunch of horse poop.

A high level language abstracts concepts like pointers and memory management, file access, graphic controls, and a lot of other things. This makes development more quick, errors less likely, cross platform development easier, access to graphics much more simple and a host of other things.

As long as the compiler is efficient, it will produce code which is every bit as quick as C.

Fact is, its much easier for newcomers whom can program in C to use GE (which is a fair amount), and if they don't, they can start learning a language that has gained wordwide acceptance by using GE. That's actually why I chose GE over other game engines; I didn't have to relearn an entirely new language specific to itself!

Now this I agree with completely.

Still, seems like your friend develloped something pretty neat there. Did he write the compiler from scratch? Congradulate him for me if he did as that is one onerous task!

That's all for me, take care H.

Yeah, that is a pretty neat thing. I wonder if he used lexx/yacc?

Fuzzy wrote:

pyrometal wrote:
I disagree here, C has a legacy and its uses are widespread across the word. The higher the level of the language the LESS efficent it becomes.

What a bunch of horse poop.

Never said high level languages didn't have great advantages, but compilers can rarely be more efficient than hand coded assembly. I was only talking about the produced machine code, NOT the programming or design process. That's one of the reason early games were programmed in asm and not C (consider a suprisingly efficent language by all standards). I just meant to say, the higher the level of abstraction, the more inefficiencies are hard to avoid when translating to target machine languages. You need some REALLY good optimizers if you want to acheive hand coded efficiency levels (and making one of these yourself is a fairly big project). Anyway, we could sit here all days and dispute this point... That's what I get for being unclear I guess. ttyl Fuzzy!

No fighting girls (He plays football after he gets done with GE forums, get him there)

Btw that was to both people I said the same thing I'm not takin' sides

pyrometal wrote:

Fuzzy wrote:

pyrometal wrote:
I disagree here, C has a legacy and its uses are widespread across the word. The higher the level of the language the LESS efficent it becomes.

What a bunch of horse poop.

Never said high level languages didn't have great advantages, but compilers can rarely be more efficient than hand coded assembly. I was only talking about the produced machine code, NOT the programming or design process. That's one of the reason early games were programmed in asm and not C (consider a suprisingly efficent language by all standards). I just meant to say, the higher the level of abstraction, the more inefficiencies are hard to avoid when translating to target machine languages. You need some REALLY good optimizers if you want to acheive hand coded efficiency levels (and making one of these yourself is a fairly big project). Anyway, we could sit here all days and dispute this point... That's what I get for being unclear I guess. ttyl Fuzzy!

Nobody posts much here, so lets continue to argue(but with lots of respect from me to you).

Again, I disagree. Remember that the compilers are written in asm, and 30 years of refinement on a decent c compiler means that all the tricks are coded in.

You can test this for yourself by writing a c program that loops several million additions using i++, i = i + 1; ++i or whatever. The compiler is going to produce the exact same output. And your efficiency at asm is going to be no greater than whoever knows enough to write a compiler. Write that exact same application in asm, and you wont get it any smaller or faster.

For example, the GNU c compiler has had thousands of eyes look at it and been refined to heck and back. The man who wrote it originally is a math genius that has been programming as long as we have been alive. Your chance of pulling off an optimization that he doesnt know are pretty slim.

I have been programming just long enough to have used older compilers. The first ones that I used were single stage compilers. The first stage would result in a partially prepared file. I think It was called a link file. From their it would be compiled to machine code.. the exe.

Since it was single pass compiling, we had to do weird things to guard against recursive references. For functions, we had to declare the function header at the beginning of the code, and then again, with the body of the function after the main loop.

Code: Select all

void somefunction(int this, float that);
void theotherfunct(int blah);

main()
{
    somefunction(5, 1.05);
}

void somefunction()
{
   stuff;
   morestuff;
   theotherfunct();
}

void theotherfunct()
{
    boo;
    hoo;
    // it really sucked.
}


I'm up for a bit of continuation also

Fuzzy wrote:Remember that the compilers are written in asm, and 30 years of refinement on a decent c compiler means that all the tricks are coded in.

Well, compilers aren't written in asm anymore, but the first ones certainly were. Unless you meant to say compilers output asm, then yes, that's entirely true. And I will also agree that nowadays C compilers are extremely optimized and output very efficient programs.

Fuzzy wrote:For example, the GNU c compiler has had thousands of eyes look at it and been refined to heck and back. The man who wrote it originally is a math genius that has been programming as long as we have been alive. Your chance of pulling off an optimization that he doesnt know are pretty slim.

haha, yes, I'll agree to this too

However, the original comment is not directed at C in particular but at languages that provide even higher levels of abstraction. In particular, I'd aim at Java's virtual machine. The idea is great without a doubt, but the obvious drawback is that any java program executed through the VM will suffer in efficiency just to get to/access the actual machine hardware for computation and etc. The same is also true for all interperted languages. A language that compiles directly into its target's machine code will not see its programs suffer from this. Of course, there exists the "just in time" compilation ability also that can solve the problem of runtime efficiency while keeping the advantages of the VM code, I am well aware of this feature.

Another toll of high level optimizing compilers is that they become bloated and large. All the checks the must perform for optimization add more and more code into the design. As a general rule of thumb, higher the abstraction of the language = more optimation checks = bigger compiler = slower compiler.

Fuzzy wrote:I have been programming just long enough to have used older compilers. The first ones that I used were single stage compilers. The first stage would result in a partially prepared file. I think It was called a link file. From their it would be compiled to machine code.. the exe.

Since it was single pass compiling, we had to do weird things to guard against recursive references. For functions, we had to declare the function header at the beginning of the code, and then again, with the body of the function after the main loop.

Hurray for multi-pass compilers, thay save us much uneeded troubles!

I really enjoy these types of conversations, I do not have many people in my surroundings with whom I can have them. I'll be waiting to see our next convergence (or divergence) of opinions! Cheers

pyrometal wrote:However, the original comment is not directed at C in particular but at languages that provide even higher levels of abstraction. In particular, I'd aim at Java's virtual machine. The idea is great without a doubt, but the obvious drawback is that any java program executed through the VM will suffer in efficiency just to get to/access the actual machine hardware for computation and etc. The same is also true for all interperted languages. A language that compiles directly into its target's machine code will not see its programs suffer from this. Of course, there exists the "just in time" compilation ability also that can solve the problem of runtime efficiency while keeping the advantages of the VM code, I am well aware of this feature.

I'm starting to see games developed in python though, and whats more highly abtracted and interpreted than that?

Another toll of high level optimizing compilers is that they become bloated and large. All the checks the must perform for optimization add more and more code into the design. As a general rule of thumb, higher the abstraction of the language = more optimation checks = bigger compiler = slower compiler.

My turn to agree with you. But the benefits of a huge compiler mean more efficient and optimized end code. As you said, the JIT and precompile techniques help lots. It was the old stuff like GWBasic that gave interpreted code a bad name more than anything.

Hurray for multi-pass compilers, thay save us much uneeded troubles!

I really enjoy these types of conversations, I do not have many people in my surroundings with whom I can have them. I'll be waiting to see our next convergence (or divergence) of opinions! Cheers

Having given it some thought, part of the single pass technique had to do with memory..

Back when, we were taught that one should code in as highly abstracted language as possible, then analyse the bottlenecks and recode in something lower. For example, you might unroll your loops and then recode the putpixel() function in asm, leaving out any error checking.

Even then it made little sense to code entirely in asm. As far as I am concerned, people eventually said "we rewrite this in asm every time, so lets just change the C compiler code for it.

And I guess you just stumbled upon the reason for my hatred of if().

Darn kids these days! When I was your age, we didnt even have try...exception blocks and we liked it that way! And get off my lawn!

Fuzzy wrote:I'm starting to see games developed in python though, and whats more highly abtracted and interpreted than that?

Nothing I'm afraid... This is only possible because of the amazing growth in computing capabilities of the hardware. Without these expanded resources, programming games in Python would only still be a dream.

Fuzzy wrote:And I guess you just stumbled upon the reason for my hatred of if().

Darn kids these days! When I was your age, we didnt even have try...exception blocks and we liked it that way! And get off my lawn!

It would be hard to get by without the "if" construct though. All it really implies is a logical branching mechanism around code blocks and is sometimes necessary. Of course, with a little thougth, a lot of these can be avoided and replaced with more efficient methods. Exception handling is a cool concept but not necessary by all means (I never resort to it when programming in C++) *smash pumpkin on Fuzzy's lawn and runs*

Have a good one!

What I want is to create a graphical programming language to be used on Game Editor!

Sounds cool makslane I'll buy a book soon as I can on C++ so I can help

makslane wrote:What I want is to create a graphical programming language to be used on Game Editor!

You know, it might be a neat concept to have a game editor with two(or more!) choices of languages. Or a mix.

pyrometal wrote:It would be hard to get by without the "if" construct though.

Agreed. Even I use them from time to time. But I find its good exercise to eliminate them. It really burns my buttons when I see "if (blah == 2)" and its obvious that blah always equals 2.

On the other hand, a big source of bugs is when people fail to allow for a variable to fall outside the scope they prepare for. What if lack of rigor allows that blah can equal 3 and they havent coded for that? Thats a hard bug to find.

Exception handling is a cool concept

Totally agreed. When I first saw I said "where has this been all these years?" Still, it sucks to see it thrown around everywhere. A good programmer can avoid a division by zero.

*smash pumpkin on Fuzzy's lawn and runs*

You little delinquent! I know where you live! I'm calling your mom!