Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Josh @ Dreamland

Issues Help Desk / Re: How to use cyrillic fonts?
« on: February 19, 2014, 11:31:49 am »
I'm assuming at least Harri is aware of this, but to clarify, it'd be stupid to include a whole unicode texture in every game. As an option, okay, maybe, at the user's own peril. A reasonable font size would put the texture well past even the high-performance GPU maximum texture size, and I really don't want to ugly up the code supporting users who want to include all unicode characters in their game. There's no rhyme or reason to it.

I believe you're trying to confirm my fears, Harri, that GM uses 0-127 ASCII and 128-255 user-specified (eg, Cyrillic). Yes? That's terribly inextensible, but would, I guess, allow us to use 0-255. But the fact remains that we use UTF-8 to store our data, and that string will be just that in memory, so processing on ENIGMA's side is going to be required. Somewhere, we'd have to find ANSI-like encoding for unicode chars in string literals, which is filthy. I'd much rather just support unicode and have users choose ranges therein, even if we have to give an interface that picks those ranges for them.

Developing ENIGMA / Re: JDI NewTemplates branch
« on: February 19, 2014, 11:19:07 am »
Well, good; your results are basically consistent with mine.
Parse completed with 510 errors and 0 warnings.

Code: [Select]
====[++++++++++++++++++++++++++++++ SUCCESS! ++++++++++++++++++++++++++++++]====

Parse completed with 510 errors and 0 warnings.

=: Command Line Interface :=================================================

Commands are single-letter; 'h' for help.
Follow commands with ENTER on non-unix.

==13522== HEAP SUMMARY:
==13522==     in use at exit: 0 bytes in 0 blocks
==13522==   total heap usage: 299,240 allocs, 299,240 frees, 18,037,235 bytes allocated
==13522== All heap blocks were freed -- no leaks are possible
==13522== For counts of detected and suppressed errors, rerun with: -v
==13522== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

I'm going to assume that your engine file will be roughly the same. I could have had you throw windows.h in with that, but there's not much point, since it's plain C.

Developing ENIGMA / Re: JDI NewTemplates branch
« on: February 19, 2014, 11:03:18 am »
We are in no position for a feature freeze right now. There will be one when we have two branches for the new compiler. The new compiler branch, when I'm done, will be considered development. Bug fixes will go to the old branch, but this will have to be short-lived, as the new compiler will come with the new instance system (it has to).

Also, I edited in the fact that you need to specify LGM's parameters. I forgot to mention that, as my own test suite was the STL.

Those who are faint of heart can just preprocess this for me:

Code: (cpp) [Select]
#include <cassert>
#include <cctype>
#include <cerrno>
#include <cfloat>
#include <ciso646>
#include <climits>
#include <clocale>
#include <cmath>
#include <csetjmp>
#include <cstdarg>
#include <cstddef>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <ctime>
#include <cwchar>
#include <cwctype>
#include <csignal>

#include <iso646.h>

#include <exception>
#include <utility>
#include <new>
#include <numeric>
#include <functional>
#include <algorithm>
#include <memory>
#include <list>
#include <deque>
#include <vector>
#include <stack>
#include <queue>
#include <set>
#include <map>
#include <limits>
#include <string>
#include <stdexcept>
#include <bitset>

#include <iomanip>    // 13
#include <streambuf>  // 58
#include <ios>        // 196
#include <ostream>    // 220
#include <locale>     // 242
#include <iterator>   // 278
#include <hash_set>   // 278
#include <istream>    // 278
#include <iostream>   // 278
#include <fstream>    // 288
#include <sstream>    // 292
#include <strstream>  // 295
#include <complex>    // 434

If you put that in file.cpp, the command [snip]g++ -E file.cpp -o preprocessed.cpp[/snip] will generate it.

The comments after the lower headers are the number of errors that will be generated by parsing only that file on linux, currently. There are a total of 500 errors remaining in all the STL, but none of them affect ENIGMA as they are not used.

Developing ENIGMA / JDI NewTemplates branch
« on: February 19, 2014, 10:51:53 am »
Hi people,

I'm going to stop playing with blocks today and try to get this last JDI error fixed, at which point ENIGMA's engine will parse without error on Linux. I was going to boot up Windows and test it, but then I realized I don't feel like doing that at all. Plus, if I have people do this, I can test on multiple systems.

I'm going to assume that the preprocessor works without error, and so for the purpose of cross-platform testing, supplement GCC's. What I need from you is to do the following:

1. Open a terminal.
2. cd to your ENIGMA folder.
3. [snip]cd ENIGMAsystem/SHELL[/snip]
3. [snip]g++ -E SHELLmain.cpp <YOUR COMMAND LINE BUILD PARAMETERS, AS PRINTED IN LGM> -o preprocessed.cpp[/snip]
4. Upload preprocessed.cpp here as an attachment, or to dropbox, or if it's small enough (which is unlikely considering you people won't stop including STL headers from main), pastebin it.
5. Link me if necessary.

This will allow me to test JDI on arbitrary machines without booting or having access to any of them. The only thing that won't be tested this way is the preprocessor, which, as I said, should be working fine.

When this is done I'm going to go ahead and merge NewTemplates into master, at which point I will recommend integration into ENIGMA, but I will not advocate it or otherwise facilitate it, as it means writing the new compiler around it can finally happen.

I am particularly looking for a Windows dump, but any platform is welcome—the more, the merrier.


Issues Help Desk / Re: How to use cyrillic fonts?
« on: February 19, 2014, 10:22:06 am »
Presently, LGM does the glyph rendering. Support for that much is iffy, but it should be easy to patch. So basically, Harri is correct. However, there's more to this problem.

The underlying issue here is that GM/ENIGMA use sprite fonts, so including all of unicode can't happen, which is why we need you to pick a range at all. I don't own GM:S; how did you specify the Cyrillic character range in it? If we know that, we can offer a similar mechanism.

The overlying issue is, due to this problem, we haven't chosen an encoding. What does the string you are trying to draw look like? Is it literally [snip]"Привет, мир!"[/snip]? While we haven't yet decided on an encoding, our go-to encoding is UTF-8. The string literal is stored in UTF-8 in our save format, and written as UTF-8 for compile, so ultimately, you'll get UTF-8 in memory.

What Harri missed is that if we do embrace UTF-8 as our encoding (which is preferable anyway, as it is more flexible), we have two new questions:
1. Who is parsing the UTF-8 for single characters? This is easy to do, but there's only one correct answer: ENIGMA.
2. How are we storing ranges? Sparse storage (a map of wide characters to glyph texture locations)? Dense range (an array with an offset and length)? Sparse ranges (a map of dense ranges by first glyph)?

All of these will be answered, but first we need to know how you as a user specify you want a given range.

The purpose of generated code is not to be pretty. ENIGMA's generated code is C++ with wildly bloated loops and gotos. GCC's generated code is then assembly with nothing but a dozen instructions for any piece of a loop, and gotos for any branching at all. That is the nature of compilation; it isn't a flaw in a compiler by any means.

Programming Help / Re: Making games in Full HD resolution 16:9 possible ?
« on: February 15, 2014, 08:26:49 am »
Jimmy, you're doing that thing again where you show up and insult random users without provocation or even context. You should probably stop that before someone removes the ability to post, or provides that context.

Programming Help / Re: get_string without a dialog
« on: February 15, 2014, 08:24:37 am »
There are some hundred good reasons to implement a custom-rendered widgets library. Ideally, one that uses ENIGMA's own functions, so it's portable. It'd have a lot of strange dependencies, but as long as it listed them in the ey file, it'd be okay. It'd solve your problem, as well as the same problem on consoles and embedded systems.

ALLCAPS BOARD / Re: I've quit using enigma and so should you!
« on: February 13, 2014, 01:58:34 pm »
Poor cheeseboy wasted all his time complaining about a project that just never changes to his will.

General ENIGMA / Re: Can't post game.
« on: February 12, 2014, 09:32:33 am »
The EDC code is all versioned, still. There hasn't been any developer interest. We have all the framework coded; all the hard parts are done. That leaves a lot of boring monotony that no one wants to do. So, it hasn't gotten done.

Anyway, I am stuck on an annoying bit of JDI—I have fixed all the errors in parsing ENIGMA's engine except one, which occurs once in instantiating vector, and twelve times in instantiating map (which does not happen in SHELLmain). The error worries me, and I hate to ship one error short of perfect.

Meanwhile, I'm addicted to Terraria—I promised a certain little boy I wouldn't beat the game without him. This was four days ago, and he's still not ready to beat the game with me. Also the thing's massive.

But yeah, you could improve ENIGMA's parse time and accuracy simply by pulling the NewTemplates branch of JDI into it. As for the new compiler, no movement, largely because it's going to be an unholy mess trying to pull the new changes into it. I've considered dropping them and rewriting the important ones, but people will bitch about regressions.

Developing ENIGMA / Re: Optimized GMX Loading
« on: February 03, 2014, 06:56:48 pm »
ENIGMA's compiler does not presently support any formats natively, including EGM. LGM has all the resource readers/writers, so from the get-go, we just let LGM do that work for us. However, formatting the data into C-friendly structures is apparently an insurmountable task for the JVM. Possibly due to the fact that Java has the opposite endianness.

Developing ENIGMA / Re: Optimized GMX Loading
« on: February 03, 2014, 12:31:16 pm »
We don't support GMX; we offer loading it and saving to it. If you're trying to compile anything other than EGM, it's not unreasonable that you should expect overhead. Of course, modules can be constructed to allow loading other formats, but those are to be considered third-party; our focus should be on making sure that using our technologies produces the best results that could possibly be expected.

Developing ENIGMA / Re: Optimized GMX Loading
« on: February 03, 2014, 12:04:12 pm »
We could cache resources, yes, but the better idea is to just have the game load from the EGM directly. Nothing needs sent at all, then. When building a standalone, the source code would simply be stripped, and optionally, the EGM appended to the executable.

Programming Help / Re: 2D multi-dimensional arrays
« on: February 03, 2014, 11:19:38 am »
Those have been broken for some time due to type resolution in the old compiler, which is hacky at best. Most of my focus in JDI was for the purpose of correctly coercing C++ expressions.

I should mention that var has GM-like matrix capabilities. [snip=EDL]var myvar; myvar[10,20] = "Your value";[/snip]

Developing ENIGMA / Re: Window Alpha and Message Box
« on: February 02, 2014, 11:21:44 am »
Three chars and a float is more consistent with the rest of the ENIGMA API. Even if four chars is more homogeneous. Ages ago, I added a draw_set_color_rgba(), whose purpose was to accept all the color components at once. Since the pipeline works in floats, I sent the data over as floats in one call. Alpha was the only parameter I didn't have to modify, because like every other function in GML (at the time, apparently), it accepted alpha as a float.

ENIGMA cannot use RGBA as a default; it would only confuse people. Existing functions treat color and opacity as different concepts. Preserving those functions and adding new alpha-sensitive functions would confuse people, and removing those functions is not an option.