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 »
601
Off-Topic / Re: Holes in everything...
« on: July 11, 2014, 05:54:13 pm »
I don't think talking about Holes in fantasy stories is even necessary. If you come to understand that every religion and every religious book is written by people, then finding plot holes is not really hard. So I won't debate about that. But the last thing you touched is actually science, so we might talk about that.
So the theory is not dismissed by prejudice. It's dismissed because scientists need verifiable evidence, which for now isn't there. If there was any evidence, I am sure scientists would acknowledge it in a heart beat. Like discoveries in the past few decades have pushed the oldest human remains back the oldest living humanoid many thousands of years. What science do best is adapt to new information.
edit: It also sucks that you could loose friends or family just because your views don't match theirs. Especially when I guess you don't want to change them or even care that they are Christians. You love them no matter what, yet they could stop loving you just because you are an atheist? How very Cristian of them... I guess the fact I live what is considered Northern Europe helps in this regard. From all my friends, family and coworkers, maybe 3 people are actually religious. Most are agnostics and many are atheists. So it's not really a problem here. Historically Latvia was actually the last place to be Christianized in the Crusades, as Latvian tribes fought it back. It meant that in the end we even have old religious traditions that have only fused with Christianity. Like our old gods were the Sun (most importantly), Thunder, Moon and some others. This naturalistic worship (like druids or something ) is actually still in respect here. So either though I'm an atheist and don't believe in any god, I still worship (in a non-religions way) nature. That is why we try to be extremely green and ecological. If anyone is actually interested I suggest reading about it a little - http://en.wikipedia.org/wiki/Latvian_mythology . Pretty original stuff (relatively speaking).
edit2:
Quote
Check out this interesting article, written by an evolutionist I might add...Sure he is actually evolutionist? Looking at some other articles by him I have my doubts. Be he could be. Doesn't matter though. His article was a good mention of many things, but sadly was very biased (even though he tried to hide it), because at least half of the things he mention there are already known to be a hoax in one way or another. He could at least mention that and let people decide. Right now it seems more like a deception. But as he is most probably not a scientist, then I didn't really expect unbiased information (aka facts) from him.
Quote
The fact is we lived among dinosaurs. Instead of acting like evolution is disproved by it and hiding it from the public or writing skeptical articles, we could just brainstorm a logical explanation behind it.Don't get ahead of yourself. There is no "fact" of that - at least not in the theories in that article. And people have found logical explanations for all of those - it's your choice to agree with those explanations or not. Nobody tries to hide anything. As I said, at least half are already known to be hoaxes or most probably be hoaxes (The Acambaro Figurines, The Ica Stones, The Granby Idol etc.). So there actually need to be solid archeological evidence for any of that before they could even be considered as a theory. Then the fact to consider is that most of the stuff mentioned in that article that is actually old is not that old (like carving on temples made in 1100AD), and by then people would have written down information on those creatures and not just carved them. If we look on things written by ancient people (like ancient greek's and so on) all the animals mentioned are ones that are know to have existed then or exists now. There are many mythological creatures though (griffins, harpy's etc.) that nobody believes to have existed and some of them (like hydras) actually look like dinosaurs. The problem with the theory that humans lived with dinosaurs is that no archeological evidence of that has been found. Oldest human remains are nowhere close the age of the oldest dinosaur remains. It would makes sense that at least some of the dino's would be a lot younger in that case. I do think ancient people knew that something must of existed before them - they probably though hundreds of years the most. They could think that because ancient people were also very likely to find the same bones. From the bones they could of thought about the size and even look of the creature. That probably is one of many things that influenced many mythological creatures.
So the theory is not dismissed by prejudice. It's dismissed because scientists need verifiable evidence, which for now isn't there. If there was any evidence, I am sure scientists would acknowledge it in a heart beat. Like discoveries in the past few decades have pushed the oldest human remains back the oldest living humanoid many thousands of years. What science do best is adapt to new information.
edit: It also sucks that you could loose friends or family just because your views don't match theirs. Especially when I guess you don't want to change them or even care that they are Christians. You love them no matter what, yet they could stop loving you just because you are an atheist? How very Cristian of them... I guess the fact I live what is considered Northern Europe helps in this regard. From all my friends, family and coworkers, maybe 3 people are actually religious. Most are agnostics and many are atheists. So it's not really a problem here. Historically Latvia was actually the last place to be Christianized in the Crusades, as Latvian tribes fought it back. It meant that in the end we even have old religious traditions that have only fused with Christianity. Like our old gods were the Sun (most importantly), Thunder, Moon and some others. This naturalistic worship (like druids or something ) is actually still in respect here. So either though I'm an atheist and don't believe in any god, I still worship (in a non-religions way) nature. That is why we try to be extremely green and ecological. If anyone is actually interested I suggest reading about it a little - http://en.wikipedia.org/wiki/Latvian_mythology . Pretty original stuff (relatively speaking).
edit2:
Quote
Compare the intellectual copacity of an apes that can use sticks to catch bugs and then look at a human mind that can create a supercomputer from scratch.So you are saying (by the whole paragraph you wrote) our intelectual capacity is closer to rodants and pigs? Intelligents doesn't really stem from biology that much. You can be a 99.99% match, but one can be a genius and the other can be no smarter than an ape.
602
Programming Help / Re: hard time debugging
« on: July 11, 2014, 12:53:23 pm »
Yeah, It's something we could improve upon.
The idea is if you launch Run->Debug, then your game is compiled in a way that they show many errors. Most common is the use of uninitialized variables - it will show the event and the trace back on where you have it. It will not show the position or the name of the variable right now though. I think we really need to add that.
It will also show things like using nonexistent resources (sprites, background etc.). In GL3 it will also show problems with shaders. All of these errors/warnings are for now outputted to console though. So if you want to see them, then you must open a new console window (cmd on windows) and run the game from there (copy the filepath+filename from LGM console). We should probably add that when you run in Debug mode console is visible from the start.
So yes, in this regard we have to still add a lot.
edit: Also, as ENIGMA's compiled .exe's are just C++, then you can also use tools like GDB. But I don't think people using ENIGMA should be forced to use a tool which is not that easy to use (it actually is easy, but uses a console, which for kids is a big no no).
The idea is if you launch Run->Debug, then your game is compiled in a way that they show many errors. Most common is the use of uninitialized variables - it will show the event and the trace back on where you have it. It will not show the position or the name of the variable right now though. I think we really need to add that.
It will also show things like using nonexistent resources (sprites, background etc.). In GL3 it will also show problems with shaders. All of these errors/warnings are for now outputted to console though. So if you want to see them, then you must open a new console window (cmd on windows) and run the game from there (copy the filepath+filename from LGM console). We should probably add that when you run in Debug mode console is visible from the start.
So yes, in this regard we have to still add a lot.
edit: Also, as ENIGMA's compiled .exe's are just C++, then you can also use tools like GDB. But I don't think people using ENIGMA should be forced to use a tool which is not that easy to use (it actually is easy, but uses a console, which for kids is a big no no).
603
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: July 10, 2014, 09:16:52 am »
No, I used the code already in ENIGMA. So no, anisotropic is still off, but there are functions for that in ENIGMA already too. I will try enabling it.
604
Developing ENIGMA / Re: Texture Handling
« on: July 10, 2014, 09:08:33 am »Quote
Yeah, exactly, that's why it won't work. By default interpolation is turned off, so wherever you are storing min/mag filter in the sampler object, that will override your per-texture information, so calling another texture function which sets it per-texture, is still going to be overridden by the sampler state, so that makes no sense.But we could make samplers to have disable/enable functions or make them disabled for the unit when the texture objects parameters change. In GL sampler objects need to be manually created for a reason. It would make A LOT more sense to have texture_sample_create() or something similar. Also, GM:S already allows using both samples (_ext functions) and the older regular way (without _ext).
Quote
No it does have to be 1-8, that specific doc doesn't mention it, but it does mention the term "slot" which is semantically defined in texture_set_stageI was specifically referring to "shader_get_sampler". I guess their semantics is gotten from DX or something, because in GL sampler is just a uniform. Just like any other. And uniforms have indices in any range (starting from 0 to MAX_UNIFORMS). So in ENIGMA, for example, they can be returned as 126 or anything else.
Also, in the two doc excerpts you quoted I feel "stage slots" and "sampler slots" are meant to be two different things. Basically, I ask you to make 20 uniforms and then 1 sampler. Check the ID the sampler returns. In ENIGMA it might be 21 (or 20), while in GM:S I guess it returns 1 (or 0)? Maybe their function just does somethings differently then the one we have in ENIGMA.
Quote
Through the function texture_set_stage and the vertex buffer functions,Multi-texturing usually doesn't require multiple UV coordinates. I plan to make Attribute functions anyway, and they would basically allow passing your own per-vertex data to shaders. This could then be wrapped in vertex buffer functions if needed, but I don't see that much of a point. I'll look into supporting those GM:S functions anyway. Other than that multitexturing is as possible in ENIGMA as it's in GM:S. You use texture_set_stage and sampler uniforms. That way you can use several textures, like to render specular highlights only on some parts of the object or make only some part of the texture glow. All of that can be done with the functions already in ENIGMA, as you usually use the same UV's for all the textures (it's even required to make all those effects). Terrain example also (by your own description) was multitexturing.
Quote
but I am not sure if the vertex buffer functions can be rendered without a shader, but judging by the fact some of their constants are FFP I am pretty certain they can.By their own description you cannot.
Quote
NOTE: You can build the primitive and store it in the vertex buffer in any step of your game, however to draw it, you must submit it during the Draw Event and only when calling a shader.And it's only logical. Making a shader that can interpret your data is basically impossible. You have to write a custom shader to use this data. I am not understanding 100% why that vertex format stuff is necessary though. I believe I can do everything it is used for without it.
Quote
I was simply stating that for an explanation as to why I didn't offer the ability to control the mipmap levelsYes, and your statement was that D3D doesn't allow and Unity doesn't either. You didn't specify WHY.
Quote
he inconsistency in RGBA color values, sometimes an int, sometimes alpha is a double, sometimes all components need specified 0-255.I agree with these kinds of things. Consistency is very important and GM often lacks it. Problem is that you cannot easily fix this without breaking a lot of compatibility even with already made ENIGMA projects. So these kinds of things need to be though out before it gets out of hand and we will just have "to deal with" (like YYG does now).
605
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: July 09, 2014, 02:55:16 pm »
I enabled mipmapping and that really did boost the whole thing almost 200FPS. Then I also optimized the shader and halved the resolution of the reflection. It actually helps a bit too, because it blurs it a little and so the reflection is not so rough. I left refraction and absorbtion resolutions the same or else there are graphical glitches (that are fixable, but I don't want to do it now). Mipmapping makes the texture repeat a lot though. Without mipmapping it adds this noise which removes this noticeable repetition.
I will try to add trees next. I have problems with rotation calculations and UV coords for them.
I will try to add trees next. I have problems with rotation calculations and UV coords for them.
606
Developing ENIGMA / Re: Texture Handling
« on: July 09, 2014, 12:58:42 pm »Quote
Not necessarily, most OGL2 hardware also support the sampler objects, it just wasn't officially approved by the ARB until then. Just search the hardware reports.I'm not talking about the hardware, but the GL version. Like GF400 supports GL4, even though it was released 3 years before GL4 actually was done. It's possible because GPU's are no longer FFP and so it's possible to add features via firmware and drivers. But it does mean the hardware/software needs to support GL3.3. Some older hardware (especially Intel) had some crappy drivers, which meant that even if it supported EXT, it didn't end up supporting ARB.
Quote
I said there is probably a way to make this more efficient.Cache it.
Quote
They added texture_set_interpolation_ext, do you want to support it or not?But can't it work with both? Because the _ext functions change parameters of the sampler, which override the parameters set by texture stage. So you should be able to keep both. They shouldn't even be refering to texture stages as far as I understand, but to uniform samplers. Like look at this function: http://docs.yoyogames.com/source/dadiospice/002_reference/drawing/texture_set_repeat_ext.html
The example they show is this:
Code: (edl) [Select]
shader_sample = shader_get_sampler_index(shader_glass, "s_NoiseSampler");
texture_set_repeat_ext(shader_sample, true);
shader_sample could in theory be anything. It doesn't need to be 0-8. It can be 240 if it's 240th uniform defined. So in this case you can override the sampler information in the shader.Maybe I am not understanding something correctly or their doc's are wrong. Previously I though that they are tied to texture stages like TEXTURE0, TEXTURE1 etc. But that is something different.
Quote
Are you saying our default shader does not support multi-texturing, because YoYoGames does, at least I think. This is strictly theoretical because they have vertex buffers which are meant for shaders, so I do not know if the multi-texturing or vertex buffers even work without shaders.How does it support multi-texturing exactly? By default you only draw 1 texture at a time - the used one. Like draw_sprite(spr_guy,0,0,0) will bind spr_guy to texture unit 0 and draw with it. There are no functions in GM or ENIGMA that allows you to do anything differently. You can of course render with as many textures as you want when writing your own shader (as demonstrated in many examples).
Quote
Uhm yes, because this thing we are talking about is how many mipmap levels are automatically generated. Unity3D does not let you specify, Direct3D9 apparently doesn't let you specify they just select the best number of mipmap levels given the texture. OpenGL does if you set the max level before calling the generate mipmaps function, I attempted what I thought was the equivalent in D3D but it didn't yield results. I do not think Direct3D11 lets you chose the number of mipmaps either. So basically, if you want to not do what everyone else is doing, we need to write our own mipmap generator, but then it won't be hardware accelerated or have hardware filtering.I actually looked in GL's spec and doc's on how the thing works. Apparently you don't need to set MAX either, by default it's 1000. But it only generates the mipmaps until smallest texture is 1x1 (so it never really goes to 1000 mipmaps unless you have a texture size 2^1000 = 10^300). So there really isn't much use in manually specifying that number unless you want to have a finer control. Like it might be useful for text, when you want it crisp even at a distance, instead of totally smoothed out, while at the same time still having mipmapping enabled for performance boost. So after finding this out I don't have a problem with not specifying the mipmapping layer number, because there is a logical and valid reason for that. Until I looked at the docs there wasn't any, but only "they did it like that".
Quote
It basically boils down to this, do you want to remain compatible with GM or not? There is really no in between anymore, there are so many differences and ways of doing things a million miles better than they did. If you don't want to support these functions, then there's no need to support any of the functions, and we should do all of the shit properly. Many places where they've fucked up makes GM harder to learn, learning to write sockets with regular scripting is easier than having some obtuse mechanism that fires events and fills data structures is the most ridiculous thing and in no way makes it easier for a noob to program, it in fact makes it harder!I have mentioned this several times before - I don't really care about GM compatibility. But that isn't up to me or you alone - many here feel totally different. They feel ENIGMA should strive for total GM compatibility. Also, I don't believe that everything GM done is bad and that we need to go in a TOTALLY different direction. I like GM's event system, I like it's instance system, it's scripting and so on. But doesn't mean we should do everything they do. Like I would want to be able to properly reference objects instead of everything being an int. While in theory it's cool and easy to use/learn, it does make a lot of the code messier, as I cannot do anything with classes. But class support for EDL should change that (still waiting for that..).
Quote
If we want to take ENIGMA in our direction then we need to start doing things the correct way and take only the important games and projects with us revising and improving them as we go and eventually fully drop GM compatibility. I for one believe this project would be a lot farther ahead if we weren't even compatible with their engine, compatibility at this point is only inhibiting the project. But I will restart my position once again, ENIGMA being a GM augmentation should be as compatible as it possible can, period. And that ENIGMA should facilitate and encourage the development of spawnoff projects and game engines.I also agree it should be as compatible as possible, but to a degree of sanity. I don't beliave a user should expect to run their GM game in ENIGMA right away, just like they wouldn't expect their UnrealEngine game to automatically work in Cryengine. Some work is always required and we can mimize it. So I think the goals of ENIGMA should be this:
1) Easy porting of GM games to ENIGMA. That means it requires a day or two usually to get a game running, especially considering that GM games are not that complex in terms of code (as GM engine handles most of the stuff). So no total rewrite required, just removing some functions, replacing some others etc.
2) People experienced with GM to feel like at home with ENIGMA. That means they don't have to really learn anything. Just open LGM and start making games. When they hit a incompatibility, they should be able to figure out the way to do it ENIGMA (either trough Intuition, Help, Wiki or Forums).
607
Developing ENIGMA / Re: Texture Handling
« on: July 08, 2014, 11:56:24 am »Quote
OpenGL3 already was slower in our tests than GL1, as far as shaders, they can only be used in GL right ?Right now it should be quite the same on both GL1 and GL3 (on a non-toaster hardware at least). And in theory it could be faster (even A LOT), but if you want to render something so basic GL1 can render it, then it will be faster in GL1. Mostly because you cannot beat the perfect optimization engineers did for GL1. But if you want something more complex, then using GL3 might not even be faster, but also the only option. Also shaders allow making particle systems on GPU's, which you make the thing run many times faster than GL1. Right now I think only GL has shaders implemented. In the end you will be able to use HLSL in DX though.
Quote
So people with DX6/7/8 cards could not run your gameWhich century PC's are you actually targeting? I only use GL3 now, because I see no reason to target anything lower. If your PC doesn't support GL3, that means your PC hasn't been upgraded in more than 6 years (like the first one that can run GL3 was GF8000 which was launched in late 2006... and you it also means that you don't want to spend less than 50$ on a card that supports GL4, because now graphics cards really are dirt cheap. So anyone who doesn't have a PC that can run GL3 is dead in my eyes, and I don't need them to use my software. That includes Mac users, which has very bad GL support (or had previously a few years ago).
608
Programming Help / Re: Calculating 3D model Normals
« on: July 07, 2014, 11:58:28 am »
The code I used in the water demo was this: http://pastebin.com/zV4gXtQg
The normal code alone is this:
edit: Also, that is about the same code that was previously in ENIGMA and Robert removed.
The normal code alone is this:
Code: [Select]
//Normal calculation
normals = ds_grid_create(3,ds_grid_width(heights)*ds_grid_height(heights));
ds_grid_clear(normals,0.0);
for(int i = 0; i < ds_list_size(indicies)-2; i += 1)
{
if (i%2){
index1 = ds_list_find_value(indicies,i+1);
index2 = ds_list_find_value(indicies,i);
index3 = ds_list_find_value(indicies,i+2);
}else{
index1 = ds_list_find_value(indicies,i);
index2 = ds_list_find_value(indicies,i+1);
index3 = ds_list_find_value(indicies,i+2);
}
x1 = ds_grid_get(vertices,0,index1); y1 = ds_grid_get(vertices,1,index1); z1 = ds_grid_get(vertices,2,index1);
x2 = ds_grid_get(vertices,0,index2); y2 = ds_grid_get(vertices,1,index2); z2 = ds_grid_get(vertices,2,index2);
x3 = ds_grid_get(vertices,0,index3); y3 = ds_grid_get(vertices,1,index3); z3 = ds_grid_get(vertices,2,index3);
//Get vector
nx1 = x3 - x1, ny1 = y3 - y1, nz1 = z3 - z1;
nx2 = x2 - x1, ny2 = y2 - y1, nz2 = z2 - z1;
//Cross
cx = ny2 * nz1 - nz2 * ny1;
cy = nz2 * nx1 - nx2 * nz1;
cz = nx2 * ny1 - ny2 * nx1;
//Normalize
L = sqrt(cx * cx + cy * cy + cz * cz);
cx /= L;
cy /= L;
cz /= L;
ds_grid_add(normals,0,index1,cx);
ds_grid_add(normals,1,index2,cy);
ds_grid_add(normals,2,index3,cz);
}
for(int i = 0; i < ds_grid_height(normals); ++i)
{
//Normalize total
L = sqrt(ds_grid_get(normals,0,i) * ds_grid_get(normals,0,i) + ds_grid_get(normals,1,i) * ds_grid_get(normals,1,i) + ds_grid_get(normals,2,i) * ds_grid_get(normals,2,i));
ds_grid_set(normals,0,i,ds_grid_get(normals,0,i)/L);
ds_grid_set(normals,1,i,ds_grid_get(normals,1,i)/L);
ds_grid_set(normals,2,i,ds_grid_get(normals,2,i)/L);
}
The calculation part is quite verbose, as I cannot use classed in EDL. But the idea is that I use indices to make triangles, and normals are then calculated for these triangles. The normals are all added up, so any vertex that is part of a triangle gets a smoother normal, which is what you described.Quote
EDIT: if push comes to shove, I can always have the normals pre-calculated and saved to the model, but I figured it will become easier to be able to calculate them during runtime if I have objects morphing and moving aroundIt won't be possible to calculate them per-frame anyway. So just add them to the model or calculate at start.
edit: Also, that is about the same code that was previously in ENIGMA and Robert removed.
609
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: July 07, 2014, 08:32:46 am »
There are no different functions for different versions of shaders. It's not a runtime problem - you cannot use GL1 and GL3 shaders TOGETHER in one project. It's impossible, because the shader version depends on the version of GL you use (which is specified when creating the window context).
Differentiating between shader types is already in as a dropdown menu. It doesn't differentiate between GL1 and GL3 shaders though. My suggestion would be to add a special GLSL1.0 selection for GL1 shaders and then trow warnings/errors when using GL1 shaders in GL3 and GL3 shaders in GL1. So when you load a project and the user switches graphics systems, he would get a compile time warning (in LGM) that it uses wrong shaders. No need to do it at runtime.
The runtime shader compile error is actually already there, but I need to wrap it in "show_error". Right now it just prints to console that shader compilation has failed.
Differentiating between shader types is already in as a dropdown menu. It doesn't differentiate between GL1 and GL3 shaders though. My suggestion would be to add a special GLSL1.0 selection for GL1 shaders and then trow warnings/errors when using GL1 shaders in GL3 and GL3 shaders in GL1. So when you load a project and the user switches graphics systems, he would get a compile time warning (in LGM) that it uses wrong shaders. No need to do it at runtime.
The runtime shader compile error is actually already there, but I need to wrap it in "show_error". Right now it just prints to console that shader compilation has failed.
610
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: July 07, 2014, 06:31:28 am »Quote
Looks nice Robert. I tested your example, and here is the result :All of that is as expected. We should maybe show it via pop-up or something that GL1 shaders don't work on GL3, GL3 shaders don't work on GL1 and GL shaders in general don't work on DX. Otherwise people will start posting "bug reports" like ego here.
Quote
On an important side note, I am getting massive framerate increases, from 100 to 500, with mipmapping enabled. We need the sampler objects worked out for OGL3 however before it can be utilized in all graphics systems.Can't wait to test it. It will probably increase FPS on my PC a lot too, because the terrain really benefits from mipmapping.
611
Developing ENIGMA / Re: Texture Handling
« on: July 07, 2014, 05:52:21 am »
1) So now we are raising GL3.2 to GL3.3? I don't have a problem with that, but it does seem we might end up with GL4 in a year. Maybe just start now.
2) I also don't understand why exactly we need to "emulate" everything YYG does? Especially if it's not that great of a decision? I have never seen problems with storing sampler information per-texture. I can see maybe one scenario where using sampler objects would be useful (like when using font textures for both rendering text, and rendering to texture!??!?), but still, not much point in my mind. I guess sampler objects are supposed to be faster, but they actually require more binding? But that is required only when changing the sampler state no?
3) Taking into account that it should only be used when changing sampler state or binding a different sampler to a texture, then I don't see why your GL1 should be slower. I haven't looked over the code, but I think you shouldn't be constantly binding samplers per frame. It's something you do once for a texture. At least cache the thing, so calling it repeatedly doesn't actually call the gl function.
4) There shouldn't be any reason to change the shader here. Texture sampler uniform is sent in G3ModelStruct.h line 599, where it just sets it to 0, because the currently used texture is bound at GL_TEXTURE0. You can just put the function in the next line if you really want to.
5) ARB didn't need to do anything. They didn't add sampler objects because no one needed them. You yourself even say that sampler data should be per-texture. It's more weird that they actually added them in GL3, not that they didn't add them in GL1. They probably added it, because there could be some fringe cases where it might be useful. But I don't see using them often myself. Maybe I will learn to understand what they are used for.
Also, things like "// Honestly not a big deal, Unity3D doesn't allow you to specify either." or "YYG did it" is not really a reason to implement or not implement something. This is a separate project and we shouldn't be doing all the stuff others are doing. If there is no logical reason to implement something other than "they did it", then we shouldn't implement it.
You can use GL3 on Windows just fine as well. If you have PC with card newer than 2008, then you should be fine. Especially if you have an Nvidia card, because Nvidia supports everything in OGL possible. So if you have a 400 generation card (released in early 2010, which is 4 years ago), then you already support GL4.4 which is the newest one.
2) I also don't understand why exactly we need to "emulate" everything YYG does? Especially if it's not that great of a decision? I have never seen problems with storing sampler information per-texture. I can see maybe one scenario where using sampler objects would be useful (like when using font textures for both rendering text, and rendering to texture!??!?), but still, not much point in my mind. I guess sampler objects are supposed to be faster, but they actually require more binding? But that is required only when changing the sampler state no?
3) Taking into account that it should only be used when changing sampler state or binding a different sampler to a texture, then I don't see why your GL1 should be slower. I haven't looked over the code, but I think you shouldn't be constantly binding samplers per frame. It's something you do once for a texture. At least cache the thing, so calling it repeatedly doesn't actually call the gl function.
4) There shouldn't be any reason to change the shader here. Texture sampler uniform is sent in G3ModelStruct.h line 599, where it just sets it to 0, because the currently used texture is bound at GL_TEXTURE0. You can just put the function in the next line if you really want to.
5) ARB didn't need to do anything. They didn't add sampler objects because no one needed them. You yourself even say that sampler data should be per-texture. It's more weird that they actually added them in GL3, not that they didn't add them in GL1. They probably added it, because there could be some fringe cases where it might be useful. But I don't see using them often myself. Maybe I will learn to understand what they are used for.
Also, things like "// Honestly not a big deal, Unity3D doesn't allow you to specify either." or "YYG did it" is not really a reason to implement or not implement something. This is a separate project and we shouldn't be doing all the stuff others are doing. If there is no logical reason to implement something other than "they did it", then we shouldn't implement it.
You can use GL3 on Windows just fine as well. If you have PC with card newer than 2008, then you should be fine. Especially if you have an Nvidia card, because Nvidia supports everything in OGL possible. So if you have a 400 generation card (released in early 2010, which is 4 years ago), then you already support GL4.4 which is the newest one.
612
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: July 06, 2014, 03:01:04 pm »
I will just post the egm. Then you will be able to remove all the EDL sugar. Also, for now there are no models. All is in the project and the island is generated each time (that is why it's always different in those screens).
613
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: July 06, 2014, 10:13:13 am »Quote
I'll test these shaders in GMS when I find the time.I haven't posted any shaders yet. They should in theory work, but what won't work is the example itself. I use EDL, so some conversion would have to be made. I also don't know how rendering 3D scene to surface works in GM now.
Fixed the z issue. Turns out I need to add depth buffer to FBO for depth buffer to work. I changed surface_create() a little to accommodate this as an option. Maybe I will add new options for data types and another option for number of texture targets. This would allow me to render to several textures at once via one shader.
Also made the foam a little less conspicuous.
edit: Why did Robert remove d3d_model_calculate_normals() function? In the commit it says that it didn't work, but didn't it? It's a very useful function. In the terrain demo I actually had to calculate normals in EDL, but I just noticed that I could of used the function that was previously in ENIGMA.
614
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: July 05, 2014, 07:29:18 pm »
Yeah, it really does need some filtering. The water is also to rough, but it's a start. I do have problems with rendering to surfaces though. I have some z-fighting or z-depth issues. Cannot figure it out.
Here is a larger image (right-click->View image):
Here you can see I don't have 60FPS even on a quite decent card. That's because none of that is optimized. I will add some stuff to ENIGMA to help with debugging.
Here is a larger image (right-click->View image):
Here you can see I don't have 60FPS even on a quite decent card. That's because none of that is optimized. I will add some stuff to ENIGMA to help with debugging.
615
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: July 05, 2014, 04:44:38 pm »
Yeah, I'm tweaking the whole thing. The texture was actually messed up, because I had repetition rate too big. So in that image texture size was like 2x2 pixels. That is why it's so grainy.
Here I added shoreline foam, refraction and absorption. Foam is the white thing around the island, refraction is when you look in the water and see trough it (hard to notice in this image) and absorption is when you see until a certain depth until you cannot see the land below. This case it's the blueish gradient with light blue on top and dark blue deeper below.
I will try to make a higher resolution screenshot. Right now everything runs in 800x600.
edit:
Here I added shoreline foam, refraction and absorption. Foam is the white thing around the island, refraction is when you look in the water and see trough it (hard to notice in this image) and absorption is when you see until a certain depth until you cannot see the land below. This case it's the blueish gradient with light blue on top and dark blue deeper below.
I will try to make a higher resolution screenshot. Right now everything runs in 800x600.
edit:
Quote
Does that same shader work in GM?I haven't tested as I don't have GM:S, but in theory it should.
Quote
Is this just for terrain or do we support multiple image'd OBJ materials?No, that would be something different. Here texture is applied automatically based on water level. So when you rise the water level, then border between land and water will always be sand. So it's based on .z coordinates and not based on a mask or something like that. But I am planning to replace it with a mask, so I could paint roads and so on. That would in theory work on any object, as you would just paint what texture is where and blend them automatically.
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 »