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 - Goombert

Programming Help / Re: C++ short delay when using CIN
« on: July 24, 2014, 03:33:13 AM »
It does take significantly longer to print to a command prompt than a Linux terminal, like we're talking 10 times slower if LGM outputted to a CMD when compiling than running all the JNA callbacks it does.

General ENIGMA / Re: Indentation Styles
« on: July 21, 2014, 03:38:36 PM »
Most websites with code boxes fuck up in Firefox for me, I actually find it really really annoying.

Off-Topic / Re: Religious wars in the programming community
« on: July 21, 2014, 04:41:21 AM »
not having answers to all questions in the whole universe doesn't show lack of ability in science, it just shows the scope of the universe.
entropy = randomness = information

General ENIGMA / Re: Indentation Styles
« on: July 21, 2014, 02:44:59 AM »
I'm not sure, what I mean is you press tab and the selected text is indented two spaces.

General ENIGMA / Re: Indentation Styles
« on: July 21, 2014, 12:08:26 AM »
For all the reasons Josh stated is why I agree with him ceteris paribus, the very fact that it opens the same everywhere is the reason it is standard in my opinion because it makes it universal.

And ironically there is a code beautifier by this name.

Also apparently Wikipedia has this all documented.

I would just prefer we all use the same indentation style, so that everything opens properly on GNU as well. I get sick of opening up source files either I or someone else edited and the formatting being all wrong, so I asked Josh and he told me to switch to 2 space, and I prefer it because of the universality so I would prefer we just all use that.

General ENIGMA / Indentation Styles
« on: July 20, 2014, 03:07:56 PM »
Well I recently provoked IsmAvatar on GitHub about two spaced indentations in which she raised some interesting counter arguments.

I also recently updated the coding techniques article to address this.

Anybody with a GitHub account respond there, otherwise respond here.

Issues Help Desk / Re: Issues on WinXP
« on: July 18, 2014, 01:37:26 AM »
Well for one, ENGIMA's setup currently does not support XP because of its lack of environment variables to installation paths that do not contain spaces.

Simple fix, go to the following line in your local copy.

Change it to the following.
Code: (YAML) [Select]
       Default-Windows: "C:/ProgramData/ENIGMA/"
Then go to the root drive, you can optionally switch C: for whatever drive, and make sure the ProgramData folder exists there, if it doesn't then create it.

Then restart ENIGMA, and the issue should be resolved.

Off-Topic / Re: Religious wars in the programming community
« on: July 18, 2014, 01:33:29 AM »
lol Josh roflmao

The more you stay in school the less prone to religious belief you are, and yet...
Yeah, or, the less prone you are to religious belief the more you stay in school.

I suggest CentOS and anything Red Hat.

General ENIGMA / Re: Sampler States and Texture Handling Poll
« on: July 16, 2014, 05:08:18 AM »
Quote from: TheExDeus
Sampler objects are tied to texture units right? So can't you just create 1 sampler object, tie that to texture unit 0, and change it's parameters with texture_set_ functions? Because normally you cannot use more than one texture in GM or ENIGMA. If you want to use more than one, then you must use custom shader, in which case you can allow more samplers to be made and modified.
Sure, but that doesn't change the fact that studio and Direct3D9 come with a default of 8.

Quote from: TheExDeus
And about the slowdown - why exactly is GL1 slower? If you cached it, then it shouldn't ever change during runtime unless manually changed. So there should be 0 performance degradation, unless calling a function of "if (changed == false) return;" somehow reduces performance.
How much do you expect me to catch it exactly? I applied a changed to each one of the state groups implemented so far, and that brought back to before any of my changes. But it does not work when you consider the hypothetical below.

* You create your two textures.
* You turn on interpolation
* You bind texture 1
* You draw something
* You bind texture 2
* You draw something
* You bind texture 1
* You draw something

If turning on interpolation registers a change and binding a texture returns it to unchanged, texture 1 will retain its interpolation, but texture 2 will not and remain completely unaffected for the duration of the program. I have not thought of a way of caching which is changed without caching the sampler state per-texture, which is even more hectic!

I personally don't really care. OGL still allows you to use both - if you bind sampler 0, then you disable sampler objects and it uses texture data. So it's totally optional. You can keep it like it is for 99% of the time, and if the user wants to use sampler objects, then you can allow it (by creating new functions, like sampler_set_filtering, sampler_create etc.).
Yes but the problem here is that Studio names their sampler functions texture_*, so how are you going to remain compatible and have texture functions that let you do things per-texture? For instance, texture_set_interpolation_ext could take either samplerid or textureid but they would all have the same parameters and there is no way to distinguish. You could override texture_set_interpolation to take texture id, but that is confusing as fuck to the user, especially when you add in wild functions like texture_set_sampler_enabled(); or the likes. I can't honestly think of a way now that they did that shit to do this nicely without it being a confusing clusterfuck.

General ENIGMA / Re: Sampler States and Texture Handling Poll
« on: July 16, 2014, 01:35:13 AM »
Ok, I will detail them for you.

Those in favor of per-texture like OpenGL

* More control over textures.
* Less interference with the GPU, most textures can be configured at startup and then left alone.

* More coding, you can't just turn on interpolation and leave it, if you want it on all for all textures you have to loop them.
* May slow down Direct3D9 since we'd have to interfere with the GPu every time you bind a texture in order to pass its sampler state to the shader or FFP.
* Much harder to perform batching, we must then determine not only when the texture changes but when its sampler state changes as well.
* Not GM compatible.

Those in favor of sampler states like Direct3D

* GM: Studio and GM8.1 compatible
* Much easier to perform automatic sprite batching and know when to flush the system.

* Extension below OpenGL3.3, so only newer hardware has it, otherwise it must be emulated, similarly to how it was being emulated before.
* Slower only for OpenGL1, OpenGL3 will run the same as before.
* More GPU interference in some cases, for a simple 2 texture example, one texture may have interpolation and the other may not, so more switching of states is required at runtime.

It is also important that I clear up a misconception, while Direct3D9 and OpenGL1 started much differently, and I am referring to the API's themselves not our implementations, Direct3D11 and OpenGL4 are pretty consistently the same now. They both allow you to create the sampler states yourselves, but Direct3D11 lacks per-texture sampler information like OpenGL.
This also happens to match the resource limits for textures. You can only have 16,000 textures, consider 4 levels per texture you get about 4,000 unique sampler objects which fit directly with the resource limits of both Direct3D and OpenGL hardware.

General ENIGMA / Sampler States and Texture Handling Poll
« on: July 16, 2014, 12:15:26 AM »
Please read the earlier topic for more discussion.

After some more digging, I found most of my initial assumptions are correct. Allow me to quote some various sources.
Quote from: DirectX vs. OpenGL
On the flip side, one of the more annoying aspects of OpenGL I've found is the tying of sampler parameters — filtering, addressing, mip map LOD bias, etc. — to textures. For a software renderer that modifies texture data for these changes, this makes sense, but it doesn't make sense for modern hardware where these are usually sampler states. It can also make sense if you consider them intrinsic to the texture, but that then breaks down if you want to do something beyond what the hardware can support. A high quality image processor really needs to support higher quality filtering than bilinear; bilinear filtering gives a really crappy gradient map. To do this, you have to emulate the higher-order filtering using lower-order filtering, and you run into the problem that if you ever need the same texture bound with different parameters in the same pass, you're screwed, because you only have one set of parameters on the texture. I do this when rendering bicubic in VirtualDub's D3D9 driver, and I can't port it to OpenGL because it's impossible to do so. I looked at the source for various OpenGL binding layers, and they all seem to emulate sampler states by pushing them into texture parameters. This sucks.
Quote from: Unity3D ShaderLab Threads
If you want to use the same texture with different filtering modes, and can't have some script executed in between, then yes, it does get tricky.

There's no separate sampler state in OpenGL (filtering and other modes are set onto a texture), so exposing it in D3D style is not easy.
The gentlemen in that post gave slightly misleading advice, OpenGL does in fact allow you to create sampler objects, but they are an extension and not officially core until 3.3
Quote from: Unity3D Manual
Texture samplers in compute shaders

Textures and samplers aren’t separate objects in Unity, so in order to use them in compute shader you have to follow some Unity specific rules:

    Either use same as texture name, with “sampler” in front (e.g. Texture2D MyTex; SamplerState samplerMyTex). In this case, sampler will be initialized to that texture’s filter/wrap/aniso settings.
    Or use one of “predefined” samplers; name has to have “Linear” or “Point” (for filter mode) and “Clamp” or “Repeat” (for wrap mode). For example, "SamplerState MyLinearClampSampler" - this will have linear filter and clamp wrap mode.

This goes back to my main premise, OpenGL did not properly abstract texture resources for being the low-level graphics API it claims to be. Now I am mostly in favor of going with a mix that allows you to create sampler objects in your own custom shaders and by default having texture information per-texture, but this is compatibility breaking. This means you would have to code each texture you want repetition for and each one you want to set the filtering of, unless you use a custom shader.

The choice is ultimately up to everyone else, as I really can't make up my mind on the issue, but I would like to see a sample of everyone's opinions.

Developing ENIGMA / Re: EnigmaFileFunctions repo
« on: July 14, 2014, 02:43:24 AM »
Of course it's hopeless Josh, it's Windows, do you got fucking blinders on or what?

I don't think I sound like a gangster, I think I sound like a stressed person that's on the rag most of the time. I don't see how I talk like a gangster.

That is about as gangster as I get.

Anyway, do whatever you want then I don't care, but I never changed any of the viewport stuff it's always been broke like that since the beginning I only made a proposal that it should be gotten rid of all together and act like a normal view system that you would expect. That said, if you want to be like Studio, implement application_surface and scale that and remove the duplicate window, only problem is not everyone has OGL fbo support and Josh and Harri haven't agreed on how to fix surfaces. So just go ahead and plug in ANGLE or another abstraction layer you want.

Also, TKG I think you should continue with your Mark the Penguin games, those are honestly the best I've seen from you, and I think they have more than potential. The graphics, specifically the sprites are also really good.

Developing ENIGMA / Re: EnigmaFileFunctions repo
« on: July 12, 2014, 10:52:38 PM »
Wow, it's about time you realize this Josh, I've been throwing carrier pigeons over the gates and into the windows at Microsoft for a while, they haven't responded. My advice to you and everyone is this, stick with a competent operating system.