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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
451
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.
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.
452
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.
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.
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.
>
Goodbye
==13522==
==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==
==13522== All heap blocks were freed -- no leaks are possible
==13522==
==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.
453
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:
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.
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.
454
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.
Cheers
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.
Cheers
455
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 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.
456
Issues Help Desk / Re: Is there any way of picking the C++ code before it is passed to the compiler
« on: February 15, 2014, 08:36:09 am »
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.
457
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.
458
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.
459
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.
460
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.
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.
461
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.
462
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.
463
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.
464
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]
I should mention that var has GM-like matrix capabilities. [snip=EDL]var myvar; myvar[10,20] = "Your value";[/snip]
465
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.
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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »