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

In other news, this bug was from a double free. The cause was two instances having the same ID, as assigned by the IDE. Both instances were assigned 100134; when the first was destroyed, it freed the rb_tree iterator for instance 100134. When the second instance was destroyed, it tried to do the same, resulting in the invalid read you see in that (incomplete) valgrind dump.

I'm going to file a bug against LGM, and tomorrow I'm going to add duplicate checking to debug mode for IDs. What a fucking bitch of an error.

I'll probably also fix the font_add new[]/delete mismatch.

Perhaps if you would make it print real debug errors instead of literally random shit, maybe you wouldn't have that problem.
If you knew the FIRST fucking thing about this system or about anything I just said, you'd realize that there is NO useful info that can be collected. This problem should NOT happen, under any circumstance, and is indicative of memory corruption, which valgrind has pointed out.

For interested parties, this is the dump of errors from valgrind here.

You can disregard the leak reports; they're from the segfault.

I'm dealing with this over IRC, forthevin. From what I gather, it is not reproducible except in his own game. It looks ugly and deep-seeded, a fact exacerbated by ENIGMA's woefully inadequate organization in the instance system, which is entirely my fault. I may have to start on my instance system refactoring plans early.

Proposals / Re: GL3 changes from immediate to retained mode
« on: August 08, 2013, 05:41:31 PM »
It may be, or it may be a timezone thing. I'm not certain. I know GitHub has had problems with time zones in the past, but I'm not sure as to why.

Anyway, 1.2 million instances seems like relatively few to be giving you such severe problems. How much memory is ENIGMA using before the collapse? If it's using like 2GB, then I have good news and bad news. The good news is, that's the maximum addressable space for a 32-bit program (which all ENIGMA games are on Windows). The bad news is that 1.2 million objects are using 2GB of RAM. What the fuck?

If it's not using 2GB of memory, then I have good news and bad news. The bad news is, something's terribly wrong with ENIGMA's instance system (which cheesewad has been hinting at in his other topic). The good news is, it's not using that much RAM.

Let me know which scenario we're looking at.

Shut up, Robert. Keep shitposting like that and I'll put you in charge of the event system. Or maybe you can have Zach write it for you. If you expect my assistance, you can accept it for what it is. Otherwise, fuck you. I'll take my leave.

Anyway. That error, known colloquially as the 14-fuck exception, happens in the event of miserable iterator failure in the engine. Particularly, in the instance system. In early stages of development, this happened when destroying instances to which iterators were held. I then implemented a central tracker for iterators, and a very simple garbage collection system for destroyed instances, to prevent any such mishaps. It should never happen, unless someone changed something.

To be honest, my guess is that in cheeseboy's great belligerence, he reverted to a four-year-old revision of ENIGMA. But assuming he'd not be stupid enough to do that and then bitch when it didn't work, I'm going to need more info. The game is doing *something* to piss off the iterator system. The info you provided isn't enough, cheeseboy; I need either your game or the IDE_EDIT_object*.h files.

Code: (C++) [Select]
    if (enigma::cleanups.find(a) == enigma::cleanups.end())
    if (enigma::cleanups.find(a) == enigma::cleanups.end())

As you can see, that only happens if for some fucking reason, the object was told to unlink itself, but then didn't register itself properly for garbage collection. Did one of you attempt to implement something new and exciting with the instance system?

And yes, as Harri pointed out right before I posted, general memory corruption could also be at play. I might need you to run Valgrind on the game, assuming it plays well with the engine.

Hi there! There may be a problem with the locale interpreter on your installation. What is the default language on your system?

Worst case scenario, run gcc -E -x c++ -v /dev/null and replace the English lines in Compilers/Linux/gcc.ey with the correct translation lines.

Unless I'm mistaken, this problem is happening because gcc is ignoring the locale change imposed by ENIGMA to give the correctsearch directories list. The sad thng is, there's a way to get GCC to just print the directories without anything else, but I don't remember what it is, and it's impossible to find on Google.

General ENIGMA / Re: Default Font Glyph
« on: August 08, 2013, 08:35:34 AM »
Sorry, Harri; that's life. There's not a damn thing I can do about the L being just big enough to not fit. Now, as for packing tightness, that's a reaaaally easy fix. You'd just need to up the width and height of the rectangles that get passed to the packing algorithm. You'd probably also need to offset the glyphs in the texture by half that margin as to avoid artifacts from clamping on the top and left edges of the texture. Interpolation gets a little ugly when that happens. The idea is that it would not matter in most games, but we've been seeing that behavior with increasing frequency...

General ENIGMA / Re: Default Font Glyph
« on: August 07, 2013, 10:32:27 PM »
The default one which is always included is 128x64 with about half the texture empty.
Okay, that's gross. The rectangle packer is supposed to generate an optimal map. If half the texture is empty, it means there were just enough glyphs to require one more resize (Each resize doubles the texture atlas size, for obvious reasons).

Anyway, font_add isn't really my biggest concern, largely because it's ugly and inconsistent between platforms, and as Harri so elegantly pointed out, we pack a default font with each game. Yes, it would be nice to be able to acquire glyphs (especially Unicode glyphs) on demand, so we might invest in the matter down the road. The rectangle packer, despite its apparent issues, is capable of adding more glyphs on the fly, as it does not do any planning in advance.

That said, perhaps we could gain a more optimal solution by providing the texture size in advance, eg, by calculating a solution, halving the larger (or vertical) side, then recomputing the map. Could you upload the texture generated on your system, Harri?

General ENIGMA / Re: Frustum Culling and View Hashing
« on: August 07, 2013, 04:20:04 PM »
with (obj_car closer than 300 pixels from obj_player) {} translates to with (obj_car) if (distance_to_object(obj_player) < 300) {}. The space map (most likely quad tree, in 2D) would not really help with that at all, unless you narrowed down only quadrants which contained pixels closer than 300 pixels. This is feasible, but would have to be specialized to make any real use of it. Otherwise, iterating quadrants would waste more time than it's worth.

Maybe a lambda expression could enable doing that in a general way... I'd have to give it some thought.

General ENIGMA / Re: ENIGMA for classroom?
« on: August 07, 2013, 02:20:31 PM »
The IDE supports unicode, and it can print unicode, but fonts, I believe, have to be ASCII. They might work with small unicode ranges, but the issue is, they're bitmap fonts, so every glyph you use must be included in the game.

General ENIGMA / Re: ENIGMA for classroom?
« on: August 07, 2013, 12:41:40 PM »
And this is where forthevin's regression testing would come into play.

Would we be able to set up your regression testing suite to ensure a set of games (particularly, those tutorials) still compiles and runs each release?

Issues Help Desk / Re: Warbird A13:02 in ENIGMA
« on: August 07, 2013, 11:56:22 AM »
I'm suspicious of your input diagnosis. Are the arrow key events never firing, or just not working properly? We've never had problems with input on Windows. It might be that something is disastrously wrong with collisions, and it just seems like it's not responding to input.

Parenting events is my job. I'm working on a whole list of things that need to happen before we have that in. You'll have to excuse the delay; I can't give a good ETA. According to Robert, this accounts for most of the issues in your game. If you like, I'll drop you a PM or email when we have that working. Since you linked us to the source, I'll add your game to my collection of games that need to work out of the box in the new version.

The last issue you mentioned may be related to the room system. Its persistence mechanism is really screwed up, as far as I know.

Announcements / Re: XInput and Gamepads
« on: August 07, 2013, 10:44:44 AM »
I did my best to emulate their original API using my own. The functions most notable in my set are joystick_map_button and joystick_map_axis, which allow you to make a joystick button behave like an arbitrary keyboard key, or a joystick axis behave like two. No other code needs written to add joystick support for your game.

Another key difference is that my joystick numbering begins at zero, as opposed to one.

Also, please tell me you made that image yourself. If you got that from Yoyo, we're about to have serious legal issues.

And one more thing: I'd rather not use an XBox controller as our only example. Microshit's worthless-fuck toolkits only support XBox controllers. I would rather use a Logitech controller to show prospective developers, "hey, we support shit that Microsoft The Great did not bestow upon us rectally!"

Announcements / Re: XInput and Gamepads
« on: August 07, 2013, 10:35:03 AM »
Yoyo's (GM's) joystick functions suck dick. They're underpowered, inconsistent, and fuck-ugly. Use my Linux joystick functions.

If any functionality is missing in my joystick functions, by all means, add more. The Linux joystick API is missing a write mechanism for such features as rumble. It's been missing this for years... So yes, feel free to add a joystick_rumble, etc.

That'd give us the same problems we're facing now; we want people to be able to link, but not from a fork project that stole our engine and revamped it with proprietary code we can't use. The license needs to be tailored to only allow linking to it legitimately. We want to allow linking general-purpose libraries, but not libraries specifically written to improve a semi-proprietary fork of ENIGMA.