What are you working on? v19 - Developers

[QUOTE=Ziks;31278925]It seems to only be sprites (not the world tiles) that have the problem, and I'm not using a triangle strip for them. The problem seems to be the texture coordinates that are sent to the shader, or how the shader interprets them. I'm pretty sure that the exact same data will be sent to the shader whatever card you have, so it must be the shader. I can't see any problems with it myself, although I am new to shader writing (and OpenGL in general). Maybe a more seasoned OpenGL user can see the problem (and probably spot some optimizations I should really have done too, like how I divide the resolution by 2 three times for every vertex). [/QUOTE] There was a program that let you test yuour shaders to make sure they would work on both ati an dnvidia cards

try changing the "texture(texture0, var_texture) * var_colour" line to "texture2D(texture0, var_texture) * var_colour"

[QUOTE=robmaister12;31279249]try changing the "texture(texture0, var_texture) * var_colour" line to "texture2D(texture0, var_texture) * var_colour"[/QUOTE] That's what it used to be. Apparently texture2D() and sampler2d is deprecated by GLSL version 130, with texture() and sampler2D respectively replacing them.

hmm fair enough, I'm still using texture2D() in GLSL 150, never really checked if it was deprecated because it works... only other thing that seems weird is the screen resolution dividing lines. What are you trying to do there?

What you could always do is move the shaders out to files and let someone with an NVIDIA card poke around till it works.

[QUOTE=robmaister12;31279504]hmm fair enough, I'm still using texture2D() in GLSL 150, never really checked if it was deprecated because it works... only other thing that seems weird is the screen resolution dividing lines. What are you trying to do there?[/QUOTE] The in_position is the coordinates from the top left of the screen in pixels. Those three lines convert it to the respective location in OpenGL's coordinate space. I'm doing it in my vertex shader instead of when I pass the vertices to the shader for convenience. [editline]23rd July 2011[/editline] [QUOTE=Lutin;31279661]What you could always do is move the shaders out to files and let someone with an NVIDIA card poke around till it works.[/QUOTE] Great idea, I'll do that tomorrow.

[QUOTE=NorthernGate;31239898]Platformer. At the beginning of each round a surge of creatures/people/things come from the left or right side of the map, they're trying to escape to the other side of the map. You must kill as many as you can before a timer hits zero. The bodies are persistent and stay in the map as phase 2 of the round and the player must use their character to drag body parts and entrails from the body to different platforms to defend against an impending meteor strike. Bigger enemies and creatures make for better defense.[/QUOTE] Could someone offer a hand with a bit of design help? I am going to try and follow this suggestion. I haven't really made a game such as this before (or ever finished one, for that matter...) so I need a tad bit of help. I am writing it in C#/XNA/Farseer. First, how should I represent the map? A grid of numbers representing entity type and position on the map? Hardcoded Level classes that make the level out of different shapes etc? Second, How should I do entities. I will be using the Farseer samples screenmanager/gamescreen/physicsgamescreen, so I thought I could have an Entity manager that would live in the game screen. An 'Entity' is a class that has a Texture2D (or an Animation for spritesheets/animated sprites), a position, rotation, scale etc. It would extend DrawableGameComponent. Then I would have PhysicsEntity, which extends entity, and it would have a Body. In its update call, it would update the entities values (position, rotation etc.) with the Body's values for these. The problem with that is that for the Entity to be able to draw and update etc, it needs to be added to the base game (Game1)'s component list because ScreenManager doesn't have something equivalent to the Components list. This isn't good because what happens when the GameScreen gets hidden? The entitie's sprite is still there. Thirdly, what about characters? I probably should have a Player class extend PhysicsEntity, and then have User and NPC and Enemy etc. extend off that? I wish this new reply window wouldn't cut words in half wrapping them when you get to the end of a line...

[QUOTE=bobthe2lol;31279973]Could someone offer a hand with a bit of design help? I am going to try and follow this suggestion. I haven't really made a game such as this before (or ever finished one, for that matter...) so I need a tad bit of help. I am writing it in C#/XNA/Farseer. First, how should I represent the map? A grid of numbers representing entity type and position on the map? Hardcoded Level classes that make the level out of different shapes etc? Second, How should I do entities. I will be using the Farseer samples screenmanager/gamescreen/physicsgamescreen, so I thought I could have an Entity manager that would live in the game screen. An 'Entity' is a class that has a Texture2D (or an Animation for spritesheets/animated sprites), a position, rotation, scale etc. It would extend DrawableGameComponent. Then I would have PhysicsEntity, which extends entity, and it would have a Body. In its update call, it would update the entities values (position, rotation etc.) with the Body's values for these. The problem with that is that for the Entity to be able to draw and update etc, it needs to be added to the base game (Game1)'s component list because ScreenManager doesn't have something equivalent to the Components list. This isn't good because what happens when the GameScreen gets hidden? The entitie's sprite is still there. Thirdly, what about characters? I probably should have a Player class extend PhysicsEntity, and then have User and NPC and Enemy etc. extend off that? I wish this new reply window wouldn't cut words in half wrapping them when you get to the end of a line...[/QUOTE] Return key. Learn how to use it.

[QUOTE=CDeansy;31280250]Return key. Learn how to use it.[/QUOTE] he does use the enter key multiple times in his post... get a higher resolution monitor?

[QUOTE=robmaister12;31280285]he does use the enter key multiple times in his post... get a higher resolution monitor?[/QUOTE] I think he meant like this

This component based entity system caused more problems than it solved. I'm copying it out, I'll save it later but I don't want to mess with it at all right now.

[IMG]http://localhostr.com/files/mf2vmsL/capture.png[/IMG] A lot more work then meets the eye... Oh and everything is batched (I'll use VBOs later) to minimize texture switches. [IMG]http://localhostr.com/files/5p0gYBo/capture.png[/IMG] It's working! I turned of the alpha channel as it's used to store some lighting information. [url=http://code.google.com/p/nrockets/]nrockets - Networked Rockets[/url] Creating a modular OpenGL 2D engine/framework. nm_engine will be cleaned up later. Time to write the shaders!

Why don't code tags have a scroll bar?!

[QUOTE=bobthe2lol;31280426]Why don't code tags have a scroll bar?![/QUOTE] Because they don't have a CSS max-height set.

Peanut butter and banana sandwich = Programmers Food of the Gods

Someone just made a WYSIWYG editor for Source shaders! Amazing stuff... [video=youtube;82AMwQGjc8Y]http://www.youtube.com/watch?v=82AMwQGjc8Y[/video] FP Thread where I found it: [url]http://www.facepunch.com/threads/1108567-Source-Shader-Editor-a-WYSIWYG-shader-editor-from-our-friend-Biohazard.-Or-that-quot-dino-mod-guy.-quot[/url]

[QUOTE=Quark:;31280672]Peanut butter and banana sandwich = Programmers Food of the Gods[/QUOTE] Zeus's favorite food? Nutella.

Awhile back, several people posted screenshots from Mandelbrot renderers. I'm not normally one to jump on a bandwagon, but it got me thinking, despite knowing plenty about OpenGL I'd never actually [i]done[/i] any shader programming. So, here's my Mandelbrot in GLSL: [URL=http://imageshack.us/photo/my-images/36/fractalgl1.png/][IMG]http://img36.imageshack.us/img36/3240/fractalgl1.png[/IMG][/URL] Every point in the complex plane has its own unique Julia set. Hold the right mouse button somewhere in the window to see the Julia set for that point: [URL=http://imageshack.us/photo/my-images/706/fractalgl2.png/][IMG]http://img706.imageshack.us/img706/2051/fractalgl2.png[/IMG][/URL] (Letting go of the right button switches back to the Mandelbrot. Left-click while holding the right mouse button to "lock in" the Julia so you can pan and zoom around on it.) Left button pans, middle-drag or mouse wheel zooms. Source code is here: [url]https://gitorious.org/fractal-gl[/url] Needs OpenGL 2.0, GLEW, gtkmm, and gtkglextmm. There's a simple build script for Linux systems, but it ought to build on Windows if you have the libraries. Next step is to replace the hard-coded gradient with a 1D texture, and figure out how to come up with a good LOD bias for mipmapping to smooth out the noisy areas near the edge of the set.

[QUOTE=bobthe2lol;31279973]Could someone offer a hand with a bit of design help? I am going to try and follow this suggestion. I haven't really made a game such as this before (or ever finished one, for that matter...) so I need a tad bit of help. I am writing it in C#/XNA/Farseer. First, how should I represent the map? A grid of numbers representing entity type and position on the map? Hardcoded Level classes that make the level out of different shapes etc? Second, How should I do entities. I will be using the Farseer samples screenmanager/gamescreen/physicsgamescreen, so I thought I could have an Entity manager that would live in the game screen. An 'Entity' is a class that has a Texture2D (or an Animation for spritesheets/animated sprites), a position, rotation, scale etc. It would extend DrawableGameComponent. Then I would have PhysicsEntity, which extends entity, and it would have a Body. In its update call, it would update the entities values (position, rotation etc.) with the Body's values for these. The problem with that is that for the Entity to be able to draw and update etc, it needs to be added to the base game (Game1)'s component list because ScreenManager doesn't have something equivalent to the Components list. This isn't good because what happens when the GameScreen gets hidden? The entitie's sprite is still there. Thirdly, what about characters? I probably should have a Player class extend PhysicsEntity, and then have User and NPC and Enemy etc. extend off that? I wish this new reply window wouldn't cut words in half wrapping them when you get to the end of a line...[/QUOTE] 1. Tile Array. For something like this, that shouldn't be too complex, assigning each entity with a character in a grid in a text file should be fine. 2. If I'm understanding right, just make a field or property in each game screen called: IsVisible, and when you create an entity you can push a screen ( the screen you want to add the entity to ) to a property of field called: Parent or Owner. Every frame check to see if the parent of the entity has it's field or property: IsVisible on or off, if it's on go ahead and render and update the entity, if its' off then don't render or update those entities. 3. That sounds fine, though maybe you should abstract in another layer for living objects that contains health, inventory, etc information, and then inherit the player, npc, and user classes off of that. Hope that helps, I'm not the best programmer in the world, but I'll do what I can.

I wish visual studio had middle click scrolling. Such a pain to do horizontal scrolling :\.

This is an 8-bit color palette rendered in the roguelike I'm working on. [img]http://img849.imageshack.us/img849/38/paletterv.png[/img] Granted, 8-bit is pretty ghetto, but I can store huge levels in memory with no issues.

Got sick of my placeholder character sprites. [img]http://i.imgur.com/xdv0z.png[/img] He's got a pretty goofy run animation that I look forward to sharing with you.

[QUOTE=Smashmaster;31281440]This is an 8-bit color palette rendered in the roguelike I'm working on. [IMG]http://img849.imageshack.us/img849/38/paletterv.png[/IMG] Granted, 8-bit is pretty ghetto, but I can store huge levels in memory with no issues.[/QUOTE] Level size should probably be independent of colors. AND. Unless you've got ~756mb levels, I suggest you just not care either way, Most people have >512mb most people I have have ~2gb. Not that you shouldn't care about RAM usage, but don't give up features to save memory when your memory footprint is not gigantic.

Wtf Mario I told you not to let the device touch water. [IMG]http://i869.photobucket.com/albums/ab255/Yournameisinvalid21/watah.png[/IMG] Okay I'll stop now.

Um, is it normal to not instantly know the purpose of something you wrote, thus you have to read it over and over again to see what it is? For example, I have a nested for loop, to loop through a c# dictionary and it has so many special rules, like the first loop's end limit needs a + 1 at the end, maybe this one needs a - 1, etc.

[QUOTE=NotoriousSpy;31283480]Um, is it normal to not instantly know the purpose of something you wrote, thus you have to read it over and over again to see what it is? For example, I have a nested for loop, to loop through a c# dictionary and it has so many special rules, like the first loop's end limit needs a + 1 at the end, maybe this one needs a - 1, etc.[/QUOTE] Comments.

[QUOTE=NotoriousSpy;31283480]Um, is it normal to not instantly know the purpose of something you wrote, thus you have to read it over and over again to see what it is?[/QUOTE] Not "normal", but it happens sometimes when you're trying to solve a problem you don't fully understand. Once you've hacked out something that seems to work, you can study it to figure out [i]why[/i] it works, and once you understand it you can probably write a better solution. :-)

A question for all of you: Is there any reason you would choose Lua over V8 ECMAScript for game logic / scripting features? My opinion is that Lua has horrible syntax compared to JS so I'd much prefer using V8 to Lua and whatnot.

[QUOTE=danharibo;31285037]A question for all of you: Is there any reason you would choose Lua over V8 ECMAScript for game logic / scripting features? My opinion is that Lua has horrible syntax compared to JS so I'd much prefer using V8 to Lua and whatnot.[/QUOTE] I'm pretty much the opposite. I think Lua has a really elegant syntax, where as VB makes me want to gag myself and force someone to force me to eat my own shit through a tube that's been sitting in an incubator for a couple of days.

[QUOTE=NorthernGate;31285159]I'm pretty much the opposite. I think Lua has a really elegant syntax, where as VB makes me want to gag myself and force someone to force me to eat my own shit through a tube that's been sitting in an incubator for a couple of days.[/QUOTE]Lua's lack of brackets make it hard to read for me, I have the same problem with Python, I prefer languages that let you use your own indentation which can be very handy for making code easier to read