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 »
391
General ENIGMA / Re: Who fixed arrays?
« on: October 12, 2014, 07:52:11 am »
Var arrays have always worked as far as I know. Like this:
What hasn't worked is this:
Code: [Select]
var arr;
arr[0] = 69;
Or just this:Code: [Select]
arr[255] = 69;
What hasn't worked is this:
Code: [Select]
local int arr[256];
arr[2] = 10;
And that is been a problem for a few years for me, as data structures and var arrays are A LOT slower than a regular C++ array. Another thing we could do is implement STL containers. But for that we need access to classes, which sadly don't work. I'm still waiting on that new parser Josh.... though seeing how the old one is band-aided all the time, it seems the development on the new one has slowed.
392
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 09, 2014, 12:10:23 pm »
Another thing we didn't try (or at least I think we didn't) is adding glXMakeCurrent after creating the temporary context, but before the glew init's. It's actually required (also on Windows), so it was my bad that I forgot to add it. Try the last commit.
393
Developing ENIGMA / Re: LateralGM 1.8.6.65
« on: October 08, 2014, 07:02:32 am »
Did you update the plugin as well? Previously I forgot and also got an error on exit.
394
Off-Topic / Re: My Windows 10 test results here
« on: October 07, 2014, 04:34:44 pm »
Page files are the same amount of ram by default. If you have 16gb of ram, you will have 16gb of pagefiles. Same with hibernation file. On Win8 the pagefile was actually 2x the ram size by default on my system. So I was quite surprised to see on my small SSD (220GB) to have 16GB+32GB = 48GB taken by them. With 16GB of RAM it's sometimes actually better to disable pagefiles entirely, as it can speed up the system (because now it writes to pagefiles even if you have free ram). I just put it at a much smaller value. Hibernation file is quite useful though, as it increases the speed of shutdown and launch.
395
General ENIGMA / Re: What if someone started legally selling an enhanced version of ENIGMA?
« on: October 06, 2014, 03:22:54 pm »
And I guess that is the issue. But I did say that you can technically write extensions in way that has 0 interference with ENIGMA, so you wouldn't use a single line from ENIGMA engine. But I don't think that is the way to go. I don't think if there is a single license that allows us what we want - allow people to sell game and extensions, but leave ENIGMA engine open source.
396
Developing ENIGMA / Re: LateralGM 1.8.6.6
« on: October 06, 2014, 03:20:35 pm »
That syntax check button spamming happened before as well. You could replicate it by just opening scripts all the time. I don't think I ever reported it, but I assumed others might have noticed it too.
397
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 06, 2014, 10:45:40 am »
You should try debug mode. It crashed on glCreateShader(), which means you either don't support shaders, glCreateShader is also NULL, or the core context just says we using something deprecated. You can also try uncommenting "//GLX_CONTEXT_PROFILE_MASK_ARB, GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB," in xlib bridge. That will turn on the compatibility context, so it's more probable that it will run. Nvidia actually discourages disabling this compatibility context (because when later even GL3.3 is deprecated, your already compiled programs will not run without it), and I actually only did it to make the code compatible with GLES. After all these changes, I will probably turn that flag back on.
398
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 06, 2014, 08:48:19 am »
It's possible then that everything was actually already working except some draw_getpixel() somewhere. So if you are unsuccessful, then I will just revert.
399
Developing ENIGMA / Re: Accessing with types and passing by strong reference
« on: October 06, 2014, 05:02:20 am »
So I can hardcode the compiler codegen as well?
Also, the standard say's _t is reserved, so I guess it's better not to call them window_t.
I'll try using your code then. Though I really have to think hard to understand it.
Also, the standard say's _t is reserved, so I guess it's better not to call them window_t.
I'll try using your code then. Though I really have to think hard to understand it.
400
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 06, 2014, 04:58:42 am »Quote
The example works.Then maybe you can try that method. Get the glXChooseFBConfig pointer and use that.
Quote
From my point of view, C++11 support would be great! I think the main concern is double-checking that MinGW on Windows has all the C++11 features we'll need. The other devs will probably have different opinions.New MinGW (that is last few years) supports C++11 just fine. We also pack our own MinGW in ENIGMA installation, so we can control what version they are using. But supporting C++11 is a lot bigger decision, for which I would want Josh's input.
Quote
Running on master compiles and runs, and then the game is unplayable (just a single blue screen and the cursor, but it's not clear if I'm actually moving, since everything is blue).But when you were running minecraft on the branch (when you also saw ground and some blocks), were you able to hit those blocks then? Because if we cannot do this context fix properly, then I might as well revert so Linux at least partly works. Because it might have been that it rendered fine (your scaling and text was still messed up, but still), and it was the world generation that broke.
You also said that you fixed the shader example segfault, by disabling the build path. Did render correctly then? Can you post a picture?
Because it seems that Linux might have worked fine for the most part. Even if you don't have a proper GL3.3 context and debugging. This can be done later.
401
Programming Help / Re: Packing bits
« on: October 06, 2014, 04:40:45 am »
It's a lot easier to pack color_t as they are integers. Here I need to pack half floats, which require a lot more magic. And 10bit integers, which are also "non standard" in C++. I know everything about strides and GL side. The problem is only packing. Making a "float floatToHalfFloatPacked(float u, float v)" function and "float floatTo10bitPacked(float nx, float ny, float nz)". I will figure it out eventually, but I just know people like Josh are really good with bit arithmetic, which I'm not.
402
Off-Topic / Re: DX12 Is it all hype or is this the holy grail of DX!
« on: October 06, 2014, 04:37:04 am »
Performance improvements == Visual improvements.
There is no technical limit on what you can draw now. You can draw a 100% real-life image with raytracing or even regular rendering. The reason why a human face isn't 100% real in game is not because we lack the algorithms or graphics technology, it's because we lack performance.
In terms of ENIGMA, we actually need to decide whether we try going for most of the newer stuff or stick with older. Normally you have fallbacks inside the code itself, so if you cannot use DX12 feature, you just use a DX11 one. We can partially do it now, because 80-90% of rendering happens in one file - XmodelStruct.h.
The same with GL. I don't have problems making a GL4.3 (at least), but I then don't want to support 3 GL versions. I barely care about GL1.1 now, as my only development effort is for GL3.3 right now.
There is no technical limit on what you can draw now. You can draw a 100% real-life image with raytracing or even regular rendering. The reason why a human face isn't 100% real in game is not because we lack the algorithms or graphics technology, it's because we lack performance.
In terms of ENIGMA, we actually need to decide whether we try going for most of the newer stuff or stick with older. Normally you have fallbacks inside the code itself, so if you cannot use DX12 feature, you just use a DX11 one. We can partially do it now, because 80-90% of rendering happens in one file - XmodelStruct.h.
The same with GL. I don't have problems making a GL4.3 (at least), but I then don't want to support 3 GL versions. I barely care about GL1.1 now, as my only development effort is for GL3.3 right now.
403
Off-Topic / Re: My Windows 10 test results here
« on: October 06, 2014, 04:30:40 am »Quote
As to 95% being programmable does not mean it will be done that way.But it is already done that way. It has been done that way for years. Even Nvidia has said that any card in Fermi, Kepler and Maxwell architectures will support DX12 API. Some of the features it won't support, like blend functions, because those aren't programmable in the current hardware. You could emulate them though, but it would a lot slower.
Quote
Might not be good financially for NVIDIA either, otherwise you buy one card now and it works for many generations of DX.......Not going to happen.Again, this is already true for many years. Just like I said about OpenGL. My card can run OpenGL4.5 (which is actually includes some of the DX12 features), while GL4.5 spec was only release this august and my card is 2 years old.
404
General ENIGMA / Re: What if someone started legally selling an enhanced version of ENIGMA?
« on: October 06, 2014, 04:04:01 am »
I would agree if people were selling extensions - that is, wholly their own code that isn't in any way related to ENIGMA's code. With extensions I mean stuff inside the Universal_Systems/Extensions. The problem is that in most cases extensions WILL use some part of ENIGMA's engine (like the path extension uses the instance class to add path_start() and path_index functions and variables) or the Particle System extension, which uses draw_sprite() and other graphics functions for drawing. Or GME, which loads a GME sound file, and then uses ENIGMA's sound_add_buffer function to make it a sound resource. On the other hand you could technically write all those extensions without using any of ENIGMA's code, and then require the user to manually do it. Like GME could only return a buffer, and ENIGMA users would have to manually use sound function to add that buffer as a sound. Or particle system could return the position of the particles, and the user would manually draw them.
So in short - You can write an extension which doesn't use any ENIGMA code. Thus I wouldn't mind them selling those extensions. But if they add a feature or a bugfix to ENIGMA (even if it is just required to run their extension), then I would want that to be open source and implementable in ENIGMA. They can sell the feature or bugfix in parallel as well if they wanted. Like GPL doesn't forbid you to sell a binary, it just requires you to supply the source with it.
So in short - You can write an extension which doesn't use any ENIGMA code. Thus I wouldn't mind them selling those extensions. But if they add a feature or a bugfix to ENIGMA (even if it is just required to run their extension), then I would want that to be open source and implementable in ENIGMA. They can sell the feature or bugfix in parallel as well if they wanted. Like GPL doesn't forbid you to sell a binary, it just requires you to supply the source with it.
405
Developing ENIGMA / Re: Accessing with types and passing by strong reference
« on: October 05, 2014, 04:56:36 pm »
I'm screwed then. I can guarantee I won't be able to change the variant or the compiler to allow this. Most I can hope for is the fact I can maybe use classes now. Then the extension will work a lot differently then the rest of ENIGMA, but still. I don't want a hundred functions just to set a freaking background image.
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 »