Pages: 1 2
  Print  
Author Topic: Christmas Plans  (Read 8891 times)
Offline (Male) Josh @ Dreamland
Posted on: December 24, 2012, 08:27:54 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2955

View Profile Email
First off, Merry Christmas to all of you. Hope you are enjoying some time off for the holidays.

The parser is behaving to expectation, which is great, considering I told you all that it would do everything short of walk on water. However, there are still two problems I see in ENIGMA that I fear will go uncorrected until they bite someone in the ass; I am going to address both of them and one personal problem here.

If you are a developer, try to pay a little attention. At least to the first two.

Problem 1: The extension system is subtly broken.
I don't know if anyone noticed this (I think HaRRi has stumbled upon it?), but the extension system is not as modular as it was designed to be due to issues with uninformed sideways casting. The compiler handles all the casting; the linker is not involved. Thus, extensions think they are the only class that enigma::object_locals inherits virtually. Issue is, they are not. Thus, since alarms are first alphabetically, they're the only extension which will work.

Contrary to popular belief, extensions were designed to facilitate adding "heavy" functions as opposed to "groups of two or more" functions. By "heavy," I mean functions that have weighty dependency that might drive someone who is interested in disk and memory efficiency to drop us a complaint about it. Maybe someone doesn't need a 16 integer array in each object (talking of alarms). Maybe it really bothers someone that their objects all need a path_index variable, as well as position and time variables for their path. The point is, extensions make it so they can remove the entire system from their game, including the local variables that weigh down their objects.

To clarify, the issue is simply that when they need alarms and paths, both extensions assume that their bytes are the first in the structure, and one of them must logically be wrong. The fix is simply to do the casting from within the engine file (which is informed as to what each extension looks like and which extensions are being included). The detriment? We have data misread and life is hard.

Presently, you access the current instance (ENIGMA's equivalent of this) using a global. There are actually a few problems with doing this:
  • Casting that global to a virtual ancestor doesn't always work (as discussed above)
  • Only one object can be this per running game per femtosecond
  • All code has to be aware of any access boundaries associated with having only one object being this at a time
By the last one, I mean loops such as with() need to be extremely cautious about the length of time for which they change the current instance pointer. So far, this has only really entailed being careful to set it back at the end of the loop. It also, again, destroys any hope for threading anything to do with instances.

The solution: I am turning the instance addressing system on its ear.
The solution is actually pretty simple. We dump the globals that represent the current instances/iterators (namely, ENIGMA_global_instance and instance_event_iterator) and we replace them with a parameter given to ENIGMA functions which modify the current instance.

So basically, instead of this function:
Code: (C++) [Select]
void motion_set(int dir, double newspeed)
{
    enigma::object_graphics* const inst = ((enigma::object_graphics*)enigma::instance_event_iterator->inst);
    inst->direction=dir;
    inst->speed=newspeed;
}

We have this function:
Code: (C++) [Select]
void motion_set(enigma::object_graphics* enigma_this, int dir, double newspeed)
{
    enigma_this->direction=dir;
    enigma_this->speed=newspeed;
}

So, not a huge difference, but enough that it will mean some chaos.

If you are worried about the parameter, don't be. That's where the new parser comes in. I have not added this yet, as the pretty printer is not written. I want everyone on board with this idea before I ship it.

This idea has been up on the proposals board for some time; we're just finally to a point where I think I'll have the free time to deal with it. I will put everything up in the ENIGMA-JDI branch before I begin the migration. I'll make a new newspost to let you know the time has come to tackle it and do regression testing, when I'm ready for the change myself.

Again, the benefits are a fixed extension system, the option of threading, and a more stable instance addressing system.

As for the central iterator list (the list of active iterators to be conscious of when deleting shit), I am still happy with it. Though I may refactor it slightly to maintain links in the list correctly instead of moving deleted iterators back (in case an iterator is reused which is expecting one type of object and instead finds another type by mistake). For now, it should be fine.

Problem 2: The Platform-Graphics bridge is ill-conceived and horrible.
The engine directory structure gives the impression that you can use OpenGL or DirectX as your library on Windows. Presently, this isn't the case, as both systems require the window to be initialized in a special way. You may be familiar with WGL and GLX; they are, respectively, the Windows GL interface and the GL-X11 interface. Code for these monsters is found right in the Platforms folder—So far we've avoided possible issues using preprocessors, but these hurt compile time and are in general unattractive.

It's been a clusterfuck so far, because we're dealing with three entities in the Platforms folder instead of one:
  • Platform-dependent code for all manner of things, including grabbing executable name and working with directories
  • Window system code; the code that creates and manipulates windows
  • Platform-specific Graphics code, eg, WGL/GLX

It's messy to separate those three items, which is why we have issues.

Solution: Create a new folder of bridge systems.
I don't care where in SHELL this folder is created, but it needs to contain folders such as Win32-OpenGL, Win32-DirectX, X11-OpenGL, etc, for each valid pairing of Window System - Graphics System.

We may also want to separate out the window system code and put it with the widget system code. This is leading to minor technicalities on Linux: The window is governed by raw X11, while the widgets are governed by GTK+. It hasn't led to any problems, but it has the potential to do so—especially on pairings in the future (eg, if some poor bastard tries to write QT widgets).

Since much of the code in the Win32/ folder was written by me when I was 16, it may be a good idea to comb over it again, anyway. If this can serve as an excuse to do so, go ahead and let it.

Personal Problem: I return to school after two weeks.
I have 14 days of freedom before I return to school, and I already need to start making preparations for that. Depending on how I tackle this semester, it may be even more work than the last. The good news? Two things: (1) the course which will generate the most work? It's on game design. That's right, the thing we've all been doing since we were 12. (2) I am taking five courses instead of six, and one of them is philosophy. For those of you who have not taken a college philosophy course, they are an easy, effortless, and even fun A if you have an open mind and don't mind some discussion.

The bad news: The game I design has to use Ogre (or Unity or XNA—Not even considering the latter, not wanting the former since I use Linux), which I have never used before.

The other good news: I intend to deal with this gracefully by writing an Ogre extension for ENIGMA. If I have to deal with Ogre, this project may as well benefit from it.


Now you are all up to speed. In summary, brace for impact.
« Last Edit: December 24, 2012, 09:27:05 AM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Josh @ Dreamland
Reply #1 Posted on: December 24, 2012, 08:52:28 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2955

View Profile Email
Also, IsmAvatar, if you're feeling left out, I have plans for you, too. I was thinking that I could forward you a frontend to the EDL tokenizer so you could get a linear lex of the code for use in the editor. Combined with the parser, it would let you format the code manually, and could also be used for syntax highlighting if you wanted dead (preprocessed-out) code to remain unhighlighted and brace/whatever matching to work accordingly. It would also let you identify which loop break and continue statements belong to, like Eclipse does. It would also let you discriminate between shit used as identifiers, shit used as declarators, and shit used as functions.

Really up to you, though; I'm not gonna put forward the effort if you have no interest in the idea.

Tell me especially if you are interested in it for bracket/parenthesis matching so I can add that in now.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TheExDeus
Reply #2 Posted on: December 24, 2012, 12:45:47 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
Sounds like a plan. I have a few problems with ENIGMA which should be fixed (and with the parser might as well will be):
1) The problems with "with(){}" in scripts. As well as global variables and such in scripts.
2) LGM's code editor auto-complete fubar'd. Doesn't scroll with the code and actually should be possible to be modified by design (like putting it at the bottom permanently).

I haven't actually checked the newest version, so maybe all this is fixed. I have quite a few via-ass made extensions for ENIGMA. Maybe there should be a separate section to upload them? Also, documentation has really stalled, but using Doxygen style to comment code really should speed that up.
Logged
Offline (Male) Josh @ Dreamland
Reply #3 Posted on: December 24, 2012, 01:31:27 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2955

View Profile Email
The system described above will fix (1). Or at least it should; I'm not sure what problem you're talking about.
IsmAvatar will have to be persuaded into doing (2), unless I finally tackle making LGM compile. Not signing up for that.

I have been using Doxygen for the new parser/systems as the plan became solid enough to permit. If you want to start documenting things with Doxygen, go ahead. There's not much benefit to doing so, though, when the systems that most need documented will need large, independent Doxygen comments anyway.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TheExDeus
Reply #4 Posted on: December 24, 2012, 07:26:01 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
I though using Doxygen with just adding comments before functions like:
Code: [Select]
/**
 * @brief This function takes the most simplest derivative of data_in (which can be a vector, deque, queue etc.) and outputs it in data_out.
 *
 * After the function data_out.size() will equal data_in.size() and the return value will be the maximum of data_out.
 *
 * @param data_in Input data container. Can be any STL container that supports [], size() and resize(). So vectors, queue, deque etc.
 * @param data_out Output data container. Can be the same types like input can, but they don't have to match.
 * @param step Optional step size for the derivative. To get the most precise result it should stay 1.
 * @return Maximum value of data_out container
 */
This is for another project where I use Doxygen, so this is not connected with ENIGMA.

There should be a template or an outline on how to do this. There are like 10 ways to comment things with doxygen and this is just one of them.
Logged
Offline (Male) Josh @ Dreamland
Reply #5 Posted on: December 25, 2012, 01:06:11 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2955

View Profile Email
Yes, you'll find JDI is riddled with those comments. They won't help you understand how a system works as a whole, only how individual functions work. If you want to document the system, you have to write up a huge, separate comment using the @page directive, then link to it from a main page (or leave it up to the user to find it in the ToC). Kind of annoying, and not something that is likely to happen considering it's just as easy to create pages on the wiki for that purpose.

I use the same style for my comments, though I don't normally put the * on every line, and I don't always explicitly say @brief.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TheExDeus
Reply #6 Posted on: December 25, 2012, 06:26:50 AM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
Well brief is needed for the "brief" description. If you don't do that, then in function list there will be no description and you will have to click on it to jump to the large description. Brief would be extra useful here, as it would be the line that is shown in auto-complete box.

Though trough writing this I realized that you probably meant, that you have the "first line is brief" thing enabled in Doxygen, not that you don't use brief at all.
Logged
Offline (Male) Josh @ Dreamland
Reply #7 Posted on: December 25, 2012, 12:27:20 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2955

View Profile Email
For future reference, by default, the first sentence is used as the brief.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Josh @ Dreamland
Reply #8 Posted on: December 27, 2012, 12:04:32 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2955

View Profile Email
Also, who among you is interested in the idea of encapsulating EDL types and functions in their own namespace? It would make it easier to deal with noise from library implementations, but it would require putting lots of shit into that namespace and using lots of shit from STDC.

In other words, we'd no longer have problems with time or list being illegal variable names unless the user specifically said, using std::list; or using namespace std;, which I intend to unify between all viable backends (meaning, in JavaScript as well).

The new parser is much, much more adept at making these distinctions, so I can probably get it to allow using types and shit as variable names (especially in compatibility mode), but this would be a fix-all.
« Last Edit: December 27, 2012, 12:07:50 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) forthevin
Reply #9 Posted on: December 28, 2012, 09:18:04 PM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
Encapsulation of EDL types and functions would be nice, especially if it solves the problems with "time" and "list" being used as variable names. How easy would it be to set up the system such that EDL types and functions can reside in both the global namespace and the EDL namespace? If it is easy, I would like the system to be set up that way, since that should enable easy step-wise migration.
Logged
Offline (Male) Josh @ Dreamland
Reply #10 Posted on: December 28, 2012, 09:52:06 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2955

View Profile Email
Simple as placing "using namespace <name here>;" in the global scope. Just like you would any other namespace. I'll set ENIGMA up to read from :: or ::edlwhatever based on a macro. After everything's migrated, or we think everything's migrated, you'll just flip that flag and try compiling.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Josh @ Dreamland
Reply #11 Posted on: December 29, 2012, 06:06:12 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2955

View Profile Email
Threw you together an avatar, HaRRi. It's all generic and shit.


Take your pick.

Forthevin gets one next. If you have any requests, state them; otherwise your avatar, too, will be made using the first InkScape filters I see.
« Last Edit: December 29, 2012, 06:54:58 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) kkg
Reply #12 Posted on: December 29, 2012, 09:45:07 PM

Member
Location: Australia
Joined: Nov 2009
Posts: 84
MSN Messenger - kamikazigames@gmail.com
View Profile Email
they all look terrible
Logged
PC: Core i7-2600 @ 3.8ghz | 4x 4gb G.Skill RipjawZ DDR3-2000 | GTX580 | Win7 x64
Time is the greatest teacher, however it kills every single one of its pupils.
Offline (Male) Josh @ Dreamland
Reply #13 Posted on: December 29, 2012, 10:45:51 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2955

View Profile Email
*shrug* I didn't spend very much time on them.
Extensions->Render->Gear
Filters->ABC->Noise Transparency
Place gears, add simple gradients, subtract circles from gears. Done.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TheExDeus
Reply #14 Posted on: December 29, 2012, 10:58:54 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
I like the current one just fine. I can make my own if I so desire.
Logged
Pages: 1 2
  Print