ENIGMA Development Environment

Well he got 4 pulled. I don't know why though, as they are not usually pulled if everything is okay. And I doubt all 4 started to be problem. He probably looks like a pirate now.

Quote

stl::containers is definitely something I need then, since I would need to pass the objects between functions, as I like to keep it clean and not do everything in main   say for example a file reading function, then passing the read large block to an encryption function and so forth, I know that the non dynamic, regular ways of doing things, it gets lost outside the function (scope).  Something I definitely do not want at this point for my specific needs

Yeah, it's useful when passing to functions, because regular arrays don't hold it's size. So if you pass an array to a function, you cannot know how large it was (so you cannot iterate over it). That requires ugly fixes like passing size as a separate argument. With containers, you always have that information. Just remember passing stuff by reference, so you don't create a copy. I had a project to do with computer vision - I passed images to functions to extract data from them.

Code: (edl) [Select]

double awesomeFunction(std::vector<std::vector<unsigned char> > img){
//Calculate something awesome and return
}I had like 20FPS, because I was passing data by value. Then I just had to pass it by reference (add &) and it jumps to 60FPS:

Code: (edl) [Select]

double awesomeFunction(std::vector<std::vector<unsigned char> > &img){
//Calculate something awesome and return
}It's something people learn early, but still something worth reminding. Especially when working with large amount of data.

Quote

I discovered the hard way back when I using GM that file functions were HORRIBLY, RIDICULOUSLY slow, but YYG must have assumed most people would use small files and never notice...... But try reading a larger binary and it's a PAIN.......  They read 1 byte at a time, and I believe ENIGMA also, since it is compatible to its GML, also uses the same method.......

Yeah, we need to address that. One suggestion I have is to have an option to load the whole file (file_open function) and then abstract that fact, so you can still use file_text_readln() and so on, but instead of doing that on the HDD, you do that in RAM. So in essence you would have a much larger speed, but still be compatible.

Quote

IN your example you are reading lines of text from a text file.  I'm guessing, model information

As the name implies, I loaded data from a CSV file. I saved point clouds in that format (as it's very easy) and used this function to load it in ENIGMA.

Quote

BTW speaking of that, if I were to code a function that uses containers, buckets, vectors, or whatever they are called, and stuff dynamically allocated (heap), in functions, can I use this in my ENIGMA projects.  Example, if I use stl containers and vector and store a large 100 MB file into for example ResRead, and do something like return ResRead, can I pass back that 100MB back the function that was called in my enigma project ?  If that is the case, then I could easily revamp the file functions and add faster more efficient ones for advanced game developers.

Well the idea is that you can use C++ in ENIGMA. So you should be able to just call "vector<double> myVector;" straight in ENIGMA. I do make calls like "glEnable(...)" in my ENIGMA projects, so I know it's possible to use stuff that is not just in ENIGMA functions. Problem is that they break GML/EDL compatibility, as you know are using classes instead of ID's. But I personally think we should end using them.

I'm really aware of C++. And i would like to learn much simplier language. Also i might misunderstand Enigma functions

1) Yes, memory is freed at the end of the program if it either crashes or if you didn't free the resources. It's done by C++ runtime (in MinGW case it's libstdc++.dll). It sometimes won't release resource handles though, so if you open a file, but don't close it, then it's possible that over time you won't be able to open new files, as the maximum open files at once has a limit per process.

This freeing of memory is true for most devices and OS's. Only some embedded stuff still doesn't do it explicitly.

2) To get size you can use sizeof(). So sizeof(resMem) will return the number of bytes used. It's the same as doing sizeof(char)*5000.

3) For dynamic arrays (or actually arrays in general) you should use stl::containers. There is very little use in using the old C arrays anymore. The containers are fast, very optimized and releases you of many stupid tasks. Like freeing the memory,

as it's done automatically.

In your array case I would suggest using a std::vector. So you could write this instead:

So pointers and "new"+"delete" is the bain of C. In C++ there are very few

The biggest thing I have written for myself in pure C++ is 10k line program for research purpose and it only used pointers in about 3 places, because of Abstract Base Class (ABS) usage.

Didn't mean to say you should switch to pascal, I reference it because it's fresh in my memory and it's compiled like C++

Gotcha, I thought you meant dynamic memory allocation, which I believe it's not possible unless you use an interpreted language. (the garbage collector)