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.
31
Off-Topic / Re: Terrena a12 - my game
« on: November 12, 2011, 08:33:40 am »
What? Not even an exception? No stack trace? Nothing?
That definitively shouldn't happen...
Does it always happen or only some times? Does it happen with all decks? All languages? I can't seem to reproduce the issue...
That definitively shouldn't happen...
Does it always happen or only some times? Does it happen with all decks? All languages? I can't seem to reproduce the issue...
32
Off-Topic / Re: Terrena a12 - my game
« on: November 11, 2011, 10:49:27 am »
The new version should make computer turns much less tedious.
Also, while I would like to make zoomed out textures more smooth, I don't know how to do so.
EDIT: Actually, mipmaps seem to be what I'm looking for. Next version will include smooth textures for zoomed out situations.
Also, while I would like to make zoomed out textures more smooth, I don't know how to do so.
EDIT: Actually, mipmaps seem to be what I'm looking for. Next version will include smooth textures for zoomed out situations.
33
Tips, Tutorials, Examples / Undefined behavior
« on: November 08, 2011, 02:15:37 pm »
Some guys from LLVM/Clang have published a bunch of posts explaining what undefined behavior in C is and what are its implications.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
This gets tricky because they add info about optimizers, so undefined behavior really doesn't always behave like one would expect.
For instance, one of the examples they give is this:
The whole thing is very interesting and, in my opinion, a must-read for all C/C++ programmers.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
This gets tricky because they add info about optimizers, so undefined behavior really doesn't always behave like one would expect.
For instance, one of the examples they give is this:
Code: [Select]
void contains_null_check(int *P) {
int dead = *P;
if (P == 0)
return;
*P = 4;
}{/code]
In the above example, one could expect that "dead" would be removed by the optimizer, so the code would be safe.
However, depending on how the optimizer is made, this may not be the case. This is a perfectly valid optimizer result:
[code]void contains_null_check_after_RNCE(int *P) {
int dead = *P;
if (false) // P was dereferenced by this point, so it can't be null
return;
*P = 4;
}
Code: [Select]
void contains_null_check_after_RNCE_and_DCE(int *P) {
//removed dead variable since it's never used.
//if(false) removed
*P = 4;
}
The whole thing is very interesting and, in my opinion, a must-read for all C/C++ programmers.
34
Proposals / Re: EDL V.Next
« on: November 08, 2011, 04:47:28 am »Quote
I don't want people to think they can flop from map to list on a whim.They can't? You mean, EDL won't feature dynamic typing?
You do realize this means massive GML incompatibility, right?
I made this entire thing assuming that dynamic typing(GML's and JavaScript's var) was a must-have for EDL.
35
Proposals / Re: EDL V.Next
« on: November 07, 2011, 06:45:10 pm »Quote
I mean, calling class::something() on a typeless variable? Fuck that. People want compile-time "too many arguments to..." errors. I can't offer that if people can flop entire class types whenever the fuck they want, without any kind of predetermination.I'm not sure what you're talking about. If you are talking about "typeless.something()" then I don't think it's possible to have a compile-time error in a dynamically typed environment. So you'd probably want to make "dynamicallytyped.something" a compile-time error(except for stuff like x, y, room_width, etc.)
If you are talking about "class::something(typeless)", then I really don't see the problem at all. I mean, there's nothing about that that the *current* EDL doesn't have right? I mean, ENIGMA already has to allow vars to be passed to GML functions, even if those GML functions are meant to be restricted to some specific types, right?
In other words, I have no idea what you mean.
Quote
foreign()? __cpp_pod__? ENIGMA_EXPORT? What the shit are these? How about, instead of dropping breadcrumb trails for the compiler, we just say what the fuck we want as we want it? Like with strong types, and by just giving access to scripting in the native language.You're in a bad mood, but anyway, I was trying to make it easier for the compiler to tell when it was supposed to be interoping with C++. ENIGMA_EXPORT was just in case you wanted to do something obscure with EDL functions(like special calling conventions, or no name mangling for instance), and is unneeded otherwise.
__cpp_pod__ was meant to help the EDL compiler know that a struct was meant to be a POD. Again, a detail many ENIGMA users wouldn't care about but important when interfacing with C++. If you think automatically detecting PODs would work and be intuitive, then I see no reason to keep it.
As for foreign(), it is - again - a way to let EDL know that it is interfacing with C++, to be careful about calling conventions and (depending on internal implementations), possibly generate wrapper functions if convenient for the compiler. Additionally, foreign() could do neat tricks such as meaningful compile-time errors like "attempting to use C++ function, but program is compiled for JS"(and if EDL was to be directly compiled to JS and use some weird trick to convert the rest of C++ to JS, foreign would be helpful to detect when to perform those interoperability tricks).
Also, you seem to be on a bad mood.
36
Proposals / Re: EDL V.Next
« on: November 07, 2011, 04:23:48 pm »
I like let, but I'd happily abandon it. I think it makes the fact that the object is going to be destroyed after that scope ends more explicit but, again, I'd be happy to drop it entirely.
37
Announcements / Re: We can't decide
« on: November 04, 2011, 06:44:16 pm »Quote
BTW ternary expressions often make code more difficult to read, even for expertsSo can ifs, whiles, etc. Pretty much any language feature can be used for obfuscation when used wrong.
That doesn't mean they don't have their uses. IMHO, ternary conditionals are awesome. My only complaint about them is their precedence.
As for size, I'm surprised LLVM is actually that big. I wonder what they include to fill up all that space.
Regarding language design, I still think merging C++ with GML and keeping all features of both is a massive task, both with and without Clang's help.
38
Proposals / EDL V.Next
« on: November 03, 2011, 05:21:02 pm »
In the announcement post Josh made, I wrote about making EDL independent of C++, with only a few select features and some interoperability functions.
I think I ought to be more specific. So I decided to post some thoughts here for discussion.
So here goes:
some script:
So, essentially, GML with a few new features.
But that's not all.
some function file. Different from plain scripts since it can contain multiple functions.
C++ file:
So, basic types: void, int, uint, char, byte, sbyte, short, ushort, long, ulong, float, double, string, vector<T>, vector<T>::iterator/const_iterator, var(if it can be considered a type at all), T*, T&, map<K, V>, map<K, V>::iterator, lambda types(?), maybe others, such as types from C++ people might find useful. Maybe vector types too? I'm pretty sure LLVM handles vector types really well.
Extra types would be defined in enigma::cpp_interop, to ensure maximum compatibility.
Additionally, one could define other types (enigma::object_id?)
I thought about all of this literally as I was writing it, so except inconsistencies, bad solutions, etc.
Fell free to discuss and take only the good parts. As you may have noticed, I have quickly scripted not only a language, but also some APIs, feel free to discard some parts of this post.
I think I ought to be more specific. So I decided to post some thoughts here for discussion.
So here goes:
some script:
Code: [Select]
//Basic EDL
var x = 1; //Single-line comment
/*block comment*/
x = 2; //reassign
//Enter static typing
int y = 3;
y = x;
x = "str";
y = x; //enigma::cast_exception
const z = 2; //type of z is inferred.
z = 3; //error
if z > 1 then begin //GML compatibility
show_message("foo");
end
So, essentially, GML with a few new features.
But that's not all.
some function file. Different from plain scripts since it can contain multiple functions.
Code: [Select]
int foo = 2;
string bar = "xyz";
vector<float> baz;
type xyz = struct __cpp_pod__ /*plain old data*/ {
enigma::cpp_interop::type_int x;
enigma::cpp_interop::type_int y;
enigma::cpp_interop::type_float z;
};
foreign(cpp) void some_namespace::some_cpp_function(xyz foo, xyz* bar, xyz& baz);
C++ file:
Code: [Select]
#include <iostream>
#include "enigma.h"
using std::cout;
using std::endl;
struct xyz{
int x;
int y;
float z;
};
namespace some_namespace {
ENIGMA_EXPORT void some_cpp_function(xyz foo, xyz* bar, xyz& baz) {
cout << "hello, world\n" << endl;
}
}
So, basic types: void, int, uint, char, byte, sbyte, short, ushort, long, ulong, float, double, string, vector<T>, vector<T>::iterator/const_iterator, var(if it can be considered a type at all), T*, T&, map<K, V>, map<K, V>::iterator, lambda types(?), maybe others, such as types from C++ people might find useful. Maybe vector types too? I'm pretty sure LLVM handles vector types really well.
Extra types would be defined in enigma::cpp_interop, to ensure maximum compatibility.
Additionally, one could define other types (enigma::object_id?)
Code: [Select]
type mycallback = void(var sender, string message);
...
mycallback self.on_talk; //statically typed fields? Maybe some other syntax?
...
self.on_talk = [](var sender, string message) { /* do something here*/ };
Code: [Select]
//Unified API to easily handle save games, in the proper directories
var app = new GameApplication("my-game-name");
var saveslot = app.createSaveSlot("slot-" + 3); //c++-style strings are the default, although I guess one could make C-style strings
let(const savegame = saveslot.open("mydata", FileAccess::Write, FileMode::Binary)) {
byte bytes[] = {12, 13, 14, 15};
savegame.write(bytes);
} //savegame goes out of scope here, so it's destructed(and therefore closed)
//also, app.deleteSlot, app.slotExists, app.openSlot, etc.
//Essentially, each game has a global GameApplication instance, each save slot has a SaveSlot, and each save slot has as many files as the developer sees fit.
//Internally, ENIGMA may decide to compress all save slot files in a single zlib file, if Josh wishes to do so
I thought about all of this literally as I was writing it, so except inconsistencies, bad solutions, etc.
Fell free to discuss and take only the good parts. As you may have noticed, I have quickly scripted not only a language, but also some APIs, feel free to discard some parts of this post.
39
Announcements / Re: We can't decide
« on: November 03, 2011, 01:12:36 pm »Quote
MinGW LD/MSysThe horror!
Quote
interpreter for C++ which, depending on its speed, could mean a native method of doing execute_string()Highly unlikely. C++ takes some time to parse. Depending on the exact implementation(e.g. which headers are imported and how they are used), it could take several seconds just to get the code compiled. We're talking about time BEFORE the code in execute_string even STARTS running.
My suggestion is something on the lines of extern "C".
Decide which features of C++ you want in EDL. C++ includes a lot of junk which you may want to ignore.
Then decide a good interface to have C++ <-> EDL interop. So people can write code directly in C++ *without* any EDL improvements, or code in EDL with limited C++ features. So effectively two compilers, but one of those is already developed so you wouldn't need to worry about it.
Example:
myfile.cpp
Code: [Select]
#include <iostream>
#include "enigma.h"
using std::cout;
using std::endl;
ENIGMA_EXPORT void my_cpp_func(int value) {
cout << value << endl;
}
interface.eci
Code: [Select]
foreign(c) function "exit" void(int : on_invalid(replace 123) );
foreign(cpp) function "my_cpp_func" void(int : on_invalid(abort) ) ; //exceptions also acceptable
hello.edl
Code: [Select]
var x = 3;
int y = 4;
my_cpp_func(x);
my_cpp_func(y);
my_cpp_func("Hello"); //Compile-time error
string z = "Hello";
my_cpp_func(z); //Run-time error
exit("Hello"); //exit with error code 123
ECI files would essentially be EDL, just like H files are C++.
In the end, link the whole thing together using whatever LD would prefer(either mingw ld or llvm ld).
Also, the syntax here is merely an example.
40
General ENIGMA / Re: Makefile is fucked
« on: October 29, 2011, 11:59:11 am »
Just to add it to the conversation, the mono(C#) guys recommend heavy separation of backend and frontend and then have a separated frontend per platform. This gives optimal integration, but also means more work.
I haven't done much Qt development myself, but at least on Linux it seems pretty decent.
Other than that, wxWidgets was fine a few years ago too. Not sure how it is today(however, they've been thinking/working on wxWidgets 3.0 for at least 4 years now and still no release, which sounds pretty bad to me).
Not sure how Lazarus compares. I was never a Pascal guy.
I haven't done much Qt development myself, but at least on Linux it seems pretty decent.
Other than that, wxWidgets was fine a few years ago too. Not sure how it is today(however, they've been thinking/working on wxWidgets 3.0 for at least 4 years now and still no release, which sounds pretty bad to me).
Not sure how Lazarus compares. I was never a Pascal guy.
41
Off-Topic / Re: Terrena a10 - my game
« on: October 15, 2011, 06:08:21 pm »
Alpha 11 available.
The rotating tile has been removed and the game should be easier to handle now(the cards should be more balanced thanks partially due to the concept of "picking a deck". Also, the initial position of the players is now random. About what whether a position is valid(for example, to move a unit), this version should make things much clearer.
The "quick action" menu not appearing in the units is a alpha 10 bug, fixed in this version.
Also, the new version has fireworks for those who win the game.
As for the other problems you listed, this version hasn't fixed them yet.
Regarding the hidden island requiring an ocean beneath - that's because the hidden island(like volcanos, jungles, etc.) are a terrain "promotion". You can see what the base terrain is by looking at the top right of the card.
The rotating tile has been removed and the game should be easier to handle now(the cards should be more balanced thanks partially due to the concept of "picking a deck". Also, the initial position of the players is now random. About what whether a position is valid(for example, to move a unit), this version should make things much clearer.
The "quick action" menu not appearing in the units is a alpha 10 bug, fixed in this version.
Also, the new version has fireworks for those who win the game.
As for the other problems you listed, this version hasn't fixed them yet.
Regarding the hidden island requiring an ocean beneath - that's because the hidden island(like volcanos, jungles, etc.) are a terrain "promotion". You can see what the base terrain is by looking at the top right of the card.
42
Proposals / Re: Laziness Buffer
« on: October 15, 2011, 04:42:36 pm »Quote
typedef signed char byte;Oh, no you didn't.
typedef unsigned char ubyte;
byte is(as of newest standards) required to be at least 8 bits, but not necessarily.
For precise sizes, see <stdint.h>(which does include int8_t and uint8_t)
Also, some languages(e.g. C#) have "byte" unsigned, and then have "sbyte", which is signed.
43
Off-Topic / Re: Terrena a10 - my game
« on: October 13, 2011, 12:10:57 pm »
Updated the game to version Alpha 10.
I'm hoping this new version is easier to understand. Intel GPU users should definitively update to this version.
There is still a lot more to add, though.
I'm hoping this new version is easier to understand. Intel GPU users should definitively update to this version.
There is still a lot more to add, though.
44
Off-Topic / Re: Terrena a7 - my game
« on: October 11, 2011, 05:40:34 pm »Quote
Very interesting game so far, I like it.Glad to know.
Quote
but it's become hard for me to figure out how to manage loading images appropriately.I don't know what's the best way, but here's what I do:
I have a class named "ImagePack" that essentially contains a Dictionary that associates strings with textures. I tell ImagePack which textures I'll need and the class loads them. Then, when I dispose the class, it disposes all textures it contains.
For instance, all terrain/unit/event textures are in an ImagePack. So in case of Game Over, the game releases all those textures.
I handle card textures a bit differently, since although cards are textures, they are generated at game-time, rather than being on some game folder. I keep those in a separate dictionary, unrelated to ImagePack, and generate those textures as needed. So if the game hasn't encountered a card yet, then that card hasn't been rendered yet either.
I hope this helps. (some of the things I said here probably also apply to other languages)
45
Off-Topic / Re: Terrena a7 - my game
« on: October 11, 2011, 10:15:53 am »Quote
If it requires .NET, I assume that it's made with C#?Correct. I'm not really a fan of other .NET languages.