[which is not derived from or based on this library]

Your license could potentially stop useful engines on top of enigma or companies that want to release multiple games with the same engine.
From a user perspective the more open the license is the better, more choices for game engines, new engine ideas being tried out etc

For reference, the CLASSPATH exception reads like so (my emphasis in bold):

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version.

It seems that games are "independent modules" (since they could be derived from GM rather than Enigma), and you could certainly include wording that indicates what kinds of files (.scr, .obj, etc.) are considered "independent".

From personal experience, I feel that you would be best served by either:

• Picking an established license, such as GPL+CLASSPATH, or
• Asking a lawyer to come up with a license that suits your needs.

Licenses are always infinitely tricky. Just look at the "oops, Tivo" example of the GPL2, which was professionally crafted. Unless you have personal legal expertise, you may want to reconsider drafting your own legal text.

Anyway, any code I contribute will have whatever exception you all choose. Good luck, licenses are a pain.

I've pushed a fix, and tested it on Linux & Windows.

I will pull that for now, but I think Josh will have something to say about that fix. That is what I mean with "hackish" while I wanted "non-hackish".

Sure, if further cleanup is necessary just let me know. At least for the moment it will build/run.

Lack of regression testing is to blame. We don't test any pull requests, including yours.

I've pushed a fix, and tested it on Linux & Windows.

Anyway, the blame is mine, I really should have known better than to change platform stuff without testing on Windows as well.

But there's some good news! I've finally got ENIGMA + DirectX9 working on this machine!

The fix is mostly duct-tape. Those templates need moved to their own header, as they are general purpose (which is why I wrote the signed-int set as well). The color_t type also needs used in more places. The point for now was to make sure it was the same size as the union. Switching gs_scalar to double might yet break it; at very least, it will waste four bytes.

Works for me. Gotta say, I'm impressed by the way the union works. Anyway, GL3 is working great now. Thanks for the fix.

Go to that file and line and change that call to GetVertexStride() :p

Yeah, I'm still getting a blank screen with that.

That's not actually my cubes demo lol it's the GM Studio one that I use to show off how much faster ENIGMA renders it.
https://www.dropbox.com/s/ro00kob8723vlsb/CUBES.zip

Also please try this file.
http://pastebin.com/AeDrDsVF

That file gives me:

Code Select Expand

Graphics_Systems/OpenGL3/GL3model.cpp: In function 'unsigned int enigma_user::d3d_model_get_stride(int)':
Graphics_Systems/OpenGL3/GL3model.cpp:93:21: error: 'class Mesh' has no member named 'GetStride'
  return meshes[id]->GetStride();

I doubt you'll be able to pack an  RGBA 4 byte color into GLfloat I already tried extensively, but be my guest :\

Ah, you're right, I was thinking of GLDouble, which I used to store colors in my polygon code... mixed 'em up.

If this earlier paste does not work.
http://pastebin.com/53CMPb6f
Please try this paste in the same file.
http://pastebin.com/3sWsAYbK

I need to know whether each of them works or not.

Neither file works. I've tried drawing text, sprites, and primitives, and all that shows is the background color.

Is your cube demo available somewhere? I might have more luck debugging the incorrect colors of GLFloat than the "can't see anything" that I'm getting now.

Try copying and pasting this code into GL3ModelStruct.cpp and see if it works.
http://pastebin.com/8BrQwT8z
It works for me, if it works for you than that is the fix we need.

I'll try it out after work. Here's hoping!

[GLFloat]

Any concerns with just doing this and calling it a day?

We can't do that because, a color element always has to be 4 bytes. You can't pack an RGBA color into a float because of the IEEE specification. All that needs done I think is the sizeof(gs_scalar) calls changed, but I am not exactly sure what to change them to.

But a GLFloat is always guaranteed to be at least 4 bytes. I think the whole point of the GL types is to ensure you have enough bytes to store things like RGBA.

Heh, either or actually

First, your hunch is a very good one; doing this fixes everything:

Code Select Expand

typedef gs_scalar VertexElement;

Isn't what you're trying to accomplish the whole point of GLfloat? From the specification:
"A four-byte precision IEEE 754-1985 floating point variable."

...and it's supported on all versions of Open GL (Linux just typedefs it to float). For Windows+DirectX, just use gs_scalar (or whatever) as you know the platform.

Any concerns with just doing this and calling it a day?

Code Select Expand

typedef GLfloat VertexElement;

As a result of me switching to use a union because IEEE does not guarantee a float will always be 4 bytes. Thus the purpose of the union is to allow storing color as 4 bytes. If you could fix that bug you would be my hero, since I can only test from Windows right now and was unable to fix it in my  Ubuntu VM as was Greg unable to fix it on his actual distro.

I'll have a look. Are you worried about float being less than 4 bytes (if so, what platforms feature this?), or are you worried that it might be 8 bytes instead of 4?

Please see my comments on the GitHub issue tracker.
https://github.com/enigma-dev/enigma-dev/issues/615

Thanks, I've added a reply.

To work with DirectX as a developer you need to install the DX SDK, however, there is only one problem with that, actually several. Microsoft's code is only compatible with MSVC so you need specific headers for DX that are made for MinGW which is in our ENIGMA redistributable which you can only obtain otherwise with MinGW versions that include DirectX from the WINE team.

Ah, that explains a lot! Now that I know where to look, this shouldn't be too difficult. Thanks for clearing that up.

Interesting, are you on Linux? Linux is already known to not be drawing with OpenGL 3 for myself and one other user as a result of a change I made in my model class most likely a result of IEEE float specification. Can you also please test some other very basic games to see if they draw for you with OGL3? These are the two things I need to know in order to get OGL3 working for everyone again.

Yep, running under Linux. Several other "test" programs I wrote don't work with GL3, but I haven't tried to narrow down the problem (since I thought it was only affecting me). Since it's a known bug in ENIGMA, I'll track down more info on the GL3 bug, and I'll try some more well-known games.

[any]

Hey all,

I've found a really nasty bug that corrupts any multi-sub-image texture when it's swapped out and reclaimed. Observe:


The first pic shows what happens on master; the second pic shows the correct behavior. The patch is here:
https://github.com/sorlok/enigma-dev/compare/texturecache_fix

And my test game:
https://drive.google.com/file/d/0B1P7NepPcOslbDlZanZNLUg2WDQ/edit?usp=sharing

Edit: Second test game, same glitch, no sub-images:
https://drive.google.com/file/d/0B1P7NepPcOslQVNBYjE1SlNKV0k/edit?usp=sharing

However, I really need someone to test this on other backends. In particular:

• DirectX9 -- I cannot, for the life of me, manage to get Enigma to work properly from SVN on Windows.
• OpenGL3 -- Everything compiles and runs, but I get no textures whatsoever (even on master).

(I've confirmed that my patch works fine on OpenGL1.)

Once I get confirmed tests for these two platforms, I'll issue a pull request. I would really appreciate your help in this; Platform-specific bugs are a real pain, and this one affects everyone.

Thanks~

Don't worry sorlok you're fine, it's the byte alignment of the font packing function, I am trying to fix it

Well, that's a relief.

Note that if you decide to use draw_text_sprite(), there is a bug with strings that rely on spaces for line-breaking. This commit mostly fixes it:
https://github.com/sorlok/enigma-dev/commit/ba018f45c5e4

...but I'm still verifying an edge case.