Pages: 1
  Print  
Author Topic: Bad C++ generation  (Read 1881 times)
Offline (Male) Midi
Posted on: October 03, 2014, 09:02:26 PM

Member
Location: Virginia
Joined: Oct 2014
Posts: 2

View Profile WWW Email
So, I opened a GMK file from GM8 Pro, just to see how the program worked, and when I built it, it said there was a C++-side compile error, and apparently it's not putting certain symbols where they belong. One such error was "C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_objectfunctionality.h:231:9: error: expected ')' before 'float'
SHELLmain.cpp:140:1: error: expected ')' at end of input".

Where does Enigma put the generated code? It looks like I'll have to debug it by hand for each cross-platform build.
Logged
Offline (Unknown gender) sorlok_reaves
Reply #1 Posted on: October 03, 2014, 09:34:24 PM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
On Windows:
C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable

On Linux:
~/.enigma

On Mac:
./ENIGMA/
Logged
Offline (Male) Goombert
Reply #2 Posted on: October 03, 2014, 10:39:00 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
If I could see the game file, I could help figure out where the parsing is screwing up, our compiler is not quite yet completed so it can finicky about some things, especially the following...

Code: (GML) [Select]
if true
  // do something
else {
  // do something else
}

Which believe it or not I see quite often in GM games and it always fails to parse. If you don't feel comfortable uploading the file here you may also send it in a PM to me, I can't really tell though without looking at some code snippets.
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.

Offline (Unknown gender) sorlok_reaves
Reply #3 Posted on: October 03, 2014, 11:34:01 PM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
There are two parsing errors I've yet to push patches for. Once of them involves variable scoping with single-line if. The other involves the decrement/increment operators. And there are plenty of other bugs that are unknown. :)

But like Robert said, it'll be easier to debug if you post the sample code.
Logged
Offline (Male) Goombert
Reply #4 Posted on: October 04, 2014, 09:28:48 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Sorlok, I'll be honest, I was more interested in overloading var for array so we can test array lengths and also to return arrays of pixel data from background functions, like background_getpixels is what I wanted to do. Studio added some of these functions which I'd also like to have. It is much easier for heightmaps and stuff, and the old way of drawing to the screen then draw_getpixel one at a time was soooooooo slow. But currently regular arrays don't even work in the parser, and to overload var we'd also have to overload std::array which I tried and failed at.
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.

Offline (Male) time-killer-games
Reply #5 Posted on: October 04, 2014, 03:02:18 PM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1167

View Profile Email
Hey I'm from Virginia too now I can rape you! :D
Logged
Offline (Unknown gender) sorlok_reaves
Reply #6 Posted on: October 04, 2014, 03:21:04 PM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
Sorlok, I'll be honest, I was more interested in overloading var for array so we can test array lengths and also to return arrays of pixel data from background functions, like background_getpixels is what I wanted to do. Studio added some of these functions which I'd also like to have. It is much easier for heightmaps and stuff, and the old way of drawing to the screen then draw_getpixel one at a time was soooooooo slow. But currently regular arrays don't even work in the parser, and to overload var we'd also have to overload std::array which I tried and failed at.

The major challenge with pushing more variable types onto variant is the semantics of other operators (like add, subtract) when differing types are involved.

The other major question is more a design issue: do we want to mirror GM:S's array syntax 100%, for example, or do it in some other way (maybe introduce a different variant type internally?) Consider the following:

Code: [Select]
var i = 10;
var p = /* some pointer */;
var s = "hi";
var a = /* some array */;
var u = i + p + s + a;

If GM supports this last line, you're just begging for hard-to-debug games.

Logged
Offline (Male) Goombert
Reply #7 Posted on: October 04, 2014, 07:38:01 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Ohh, yeah I agree sorlok. I can't say for sure but I know the following are possible.
http://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/data%20types.html
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.

Pages: 1
  Print