Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 13 Sep 2012
Offline Last Active Today, 04:32 PM

#5207267 Some programmers actually hate OOP languages? WHAT?!

Posted by TheChubu on 28 January 2015 - 02:44 PM

in other words, many of the things people call "typical C++ bullshit" or "typical OOP bullshit" is actually "typical Java bullshit" that's been drug into C++ by recent grads or Java refuges who don't know how to write idiomatic C++ and so write idiomatic Java in C++ instead.
Now that might be just me but it sounds awfully like a "dey took our jibs!" reasoning there. Must be those filthy Java programmers, et cetera. Also you seem to assume colleges teach "idiomatic Java", I'm going to tell you they don't. They teach generic OO concepts, often badly, no matter the language they end up actually using. 


I'd say that the main reason few people write "idiomatic" C++ is because C++ is an impenetrable mess rather than other languages having obviously spoiled your programmers. Moreover, "idiomatic C++" that takes advantage of all the features of the language guarantees the codebase will become an impenetrable mess. There is no such thing as "idiomatic C++", you can get as idiomatic as the subset of features your project limits itself to allows you to, doing anything else ends up in madness and despair.


Also, turns out that many of your so called "idioms" of C++ are actually beneficial for Java and for any language. Avoid heap allocations, avoid virtual function calls*, branching has a cost, pointer indirection has a cost, and so on. I agree with exceptions there, they're just annoying, then again I'd say exceptions are a big thing on "enterprisey" software, regardless of the language.


Now if these people don't even know generic beneficial idioms that would help them no matter the language, then I don't see why you would put that on Java's shoulders.


*Although this is specific to OO languages. Also there are Java-specific considerations here, JIT can inline the virtual call if it only sees one or two concrete implementations.

#5206809 FBO only renders to the first target

Posted by TheChubu on 26 January 2015 - 07:32 PM

. They aren't relative to each other for some reason in lwjgl 
They do are from what I've used in LWJGL 2.9.2 and LWJGL 3. They take the values directly from OGL headers.


This is from LWJGL 3:

GL_COLOR_ATTACHMENT0        = 0x8CE0, // Thats 36064
GL_COLOR_ATTACHMENT1        = 0x8CE1, // 36065
GL_COLOR_ATTACHMENT2        = 0x8CE2, // 36066
... etc

#5206766 Why is this taboo?

Posted by TheChubu on 26 January 2015 - 03:31 PM

Because it is very well known that 2D platformer protagonists absorb vital energy from mystical roasted turkeys found deep inside the foundations of old castles.

#5206603 Best way to source and organise a massive Objects interaction

Posted by TheChubu on 25 January 2015 - 02:35 PM

Yes, this is potentially a huge project and there will be a team of people working on it. Do you know of standard software that does some or most of such a job? There are muliplayer games out there that do this eg Second Life so do they write from scratch or use standard products as a base?

You'll have to go with a commercial engine probably, like Unity or Unreal Engine 4. You won't be able to use visual basic with them as far as I know though.


Otherwise it will go well beyond 50k lines. Take an example, Quake 3 Arena, pretty old game, released in 1999. Basic physics, no interaction with the environment, very few players per map, all there is for the player is to jump and shoot, its around 300k lines of C. Minecraft is a bit over 300k lines of Java (although unlike ID's stuff, it isn't a landmark of good videogame code). Big commercial modern engines like UE4 or Unity go beyond 1 million lines of code mark.


3. Each object has Methods (ready made or deduced by the Genetic Programming algorithm in the program) which allows it to interact with the other objects
4. The user can then either just let it run to observe what happens (Simulator mode). Or it can solve problems eg "How can the man escape the Lion?"

Yes but you need to pin point exactly what kind of interactions are we dealing here because you'll have to code each of them. Man escaping the lion requires a man to be animated, a lion to be animated, a man AI, a lion AI, etc.


If the action is "push an object" that's easier if you have a physics engine, if the action is "pick up an object" it could be as hard as having to animate the player picking up the object, rigging the object to the player, or just making the object disappear and list it on a player inventory.


And that's like that if you already have an animation system, physics engine, rendering engine, AI system, inventory management, textures, models, animations, loaders for all of them, and a big ass et cetera. Otherwise you'll have to code it all.


I assumed that in many Games this is what the designer would do ie download ready made objects for the players to interact with.
Stock objects downloaded and used as-is are pretty much frowned upon (much like direct unmodified sampling in songs). Designing the look of a game takes time, and maintaining that style pretty much demands assets to be made specifically for each project, or at least tweaking of existing assets so they don't look off. All of this doesn't just requires effort but also having people in the team with good art skills.

#5206432 Best way to source and organise a massive Objects interaction

Posted by TheChubu on 24 January 2015 - 01:12 PM

A. The best source of objects and environments
B. The best language to use with vb.net to manipulate objects in 3D and enable them to interact
I have no clue what you mean. At all.


"source of objects and enviroments" ? What? What do you mean by "objects" ? What do you mean by "enviroments" ? What do you mean by "source" ?


"enable them to interact" ? You need to specify exactly what kind of "interaction" are we talking here, what kind of "manipulation" you want.

#5205902 OpenGL to DirectX

Posted by TheChubu on 21 January 2015 - 08:04 PM

But if you want the highest of the high level of graphics, super AAA quality rendering, then OpenGl is inferior. Maybe the latest version is great, but the ones I tried were a lot behind. For starters, a big chunk of OpenGL is implemented in the GPU driver. There is a huge quality gap between supper cheap GPUs never meant to do real rendering work and high quality stuff.
[citation needed]

#5205800 OpenGL to DirectX

Posted by TheChubu on 21 January 2015 - 10:47 AM

i look for Introduction to 3D Game Programming with Direct3D 11.0 by frank de luna, but it's all about rendering.

It happens that's all you'll use D3D or OpenGL for. They're rendering APIs, they don't handle collisions, they don't handle animations, you have to implement those, then draw them appropriately with the API.


I really want to learn DirectX first but I cant find any good tutorial that actually make a simple 3d game

 That is because making a "simple 3D game" from scratch isn't tutorial material, its book material. 3D games aren't simple.


I wont chime in the D3D or GL first debate, but I'll say that if you go the D3D route, start with D3D11, if you go the OpenGL route, start with OpenGL 3.3 or higher.


EDIT: Fuck the editor. Now it messes up quote blocks too. Ugh...

#5205798 Javascript/C++ Combo Questions (Networking/Tools)

Posted by TheChubu on 21 January 2015 - 10:39 AM

Or is this bad practice that I change later?
If you do it in JS and then change it to C++, it isn't "bad practice", that just means requirements weren't what you thought they'd be. Its fine, it happens, and the next time you have to implement something related, you'll know the right answer.

#5205103 Download Library of 3D models.

Posted by TheChubu on 18 January 2015 - 12:33 PM

My environment Code: Blocs, which also imposes certain conditions.
That have nothing to do with the code itself.


Calls will be exactly the same using Visual Studio, Code::Blocks, Xcode, QtCreator, or an hex editor and lots of patience. Code will be the same. The only thing that will differ is the menus for linking the libraries to your project.

#5205081 What are the possible ways of making a level editor?

Posted by TheChubu on 18 January 2015 - 10:02 AM

Would you have any tips on how I could dissect an image in java to use it as a level?
Read the image, fetch pixel by pixel, assign tile according to color. If your maps are 50x50, you'd have a 50x50 image, each pixel having a specific color that corresponds to a specific tile. That way you could "draw" maps with paint or anything really.


Java can read pngs, jpgs and gifs by default into a BufferedImage with the ImageIO class, its filled with static utility methods.

#5204995 Porting my game to Linux

Posted by TheChubu on 17 January 2015 - 07:52 PM

I'd say, make it work on Debian and Arch. Debian derivatives (not necessarely Debian itself) are the most popular distros out there (SteamOS, Ubuntu, Mint, etc). If there is any Linux gamer, it will probably be using one of those.


Now, I don't know exactly why, but Arch Linux and derivatives are very popular for Linux gamers too. ie, if you go to Steam forums, Linux people will say they use either Arch/Arch-based distro or Debian/Debian-based distro.


Although the actual point is: Don't try to "support Linux", just try to support most popular distros. Supporting all the Linux/BSD out there will lead you to madness and despair, and you dont want that.

#5204106 Basic OpenGL State Machine Questions

Posted by TheChubu on 13 January 2015 - 07:07 PM

i.e. Say I have a Vertex Array with two possible sets of vertices stored, respectively, in vboID and vboID_2. Is it not possible to swap between those vertex arrays as inputs to my vertex shader without re-calling glBufferData?
Yeah you can. Just bind the VAO and modify its state appropiately. ie, bind VBO, and set the vertex pointer to the attribute location you want (say, put VBO 2 into location 0). But you're not modifying the actual data there, you asked for changing the data in the OP, thats why I mentioned glBufferSubData. 


In what you say you're just modifying the state of the VAO, not the contents of each individual VBO. Nothing prevents you from binding a VBO to location 1, then another to location 3, then in another time rebind them to different locations (say, 2 and 4), if thats what you want.


Just have in mind glVertexAttribPointer and glEnableVertexArray modify VAO state, thats all they do. If you want to disable VBOs or change their format/location, just change the state of the VAO like you did before with the appropiate calls. Then when you want to draw with it, just bind the VAO and issue the draw call.


Now, say that you want vbo1 in location 0, vbo2 in location 1, then in a different time you want vbo2 in location 0 and vbo1 in location 1. You could have a single VAO for them, then modify the attribute location, or you could have two separate VAOs, binding to one VAO vbo1 to location 0, vbo2 to location 1, then to the other VAO you'd bind vbo2 to location 0 then vbo1 to location 1. In that case to switch locations you'd bind the respective VAO, without modifying their state again.


In short, VAO state is not set in stone, you can change it whenever you want. Also VBOs do not need to be bound to a single VAO, you can bind them to as many VAOs you want, and in each of those VAOs the VBOs can be bound with different formats with glVertexAttribPointer.


VBOs contain the data, VAOs specify how that data will be fed to the shader.

#5204092 Basic OpenGL State Machine Questions

Posted by TheChubu on 13 January 2015 - 06:36 PM

what if I want to change the data that is passed in the Vertex Buffer at runtime

glBufferData does two things, it allocates a buffer and it uploads to it the data you passed as parameter (or nothing if you passed null).


For changing the data of said buffer you can either call glBufferData again, which will "orphan" it (ie, reallocate the buffer) or you could call glBufferSubData, which will update the data of said buffer to whatever you pass to it.


Think of it as a contrived way to write values into a plain array of bytes, mostly because it is.


EDIT: Oops, forgot about the rest.


Is the state set in glVertexAttribPointer in the above invocation somehow "saved" to the vertex array object?

Yes! Thats exactly why vertex array objects are there for, so you don't have to call glVertexAttribPointer again for that VAO.


In your second example, the glVertexAttribPointer is redundant (oh and the glEnableVertexAttribArray call too! Thats also saved in the VAO, vertex format and enabled attributes). By binding the VAO whatever format you specified for the vertices with glVertexAttribPointer before comes into effect.

#5203482 About computer instruction in relation to RAM consumption

Posted by TheChubu on 11 January 2015 - 09:29 AM

I might be voicing an unpopular opinion here but seriously warnexus, do you ever learn anything from these topics?


You have been a member of this forum for a little bit longer than me, and looking at your post history it seems to me that if you ever paid attention to your own previous threads you would be able to answer all of this on your own by now.


Now don't misunderstand me, I'm all for learning, I'm all for curiosity. But it seems to me that after all this time, you're going nowhere:










And so on, thats just from this year. People have given you very detailed answers with a lot of good information for years. Your questions always seem to stem from some deep misunderstandings that never quite go away.


I know, I'm rambling, offtopic and I'm also being rude, but I'm just totally baffled about this, honestly.

#5203477 OpenGL samplers, textures and texture units (design question)

Posted by TheChubu on 11 January 2015 - 09:09 AM

I'm not entirely sure this could be applied effectively for bigger projects, but as a way to simplify all of this I decided simply to fix samplers to specific texture units.


For example, texture unit 0 is diffuse texture, texture unit 1 is normal map, texture unit 2 is glow map, etc. That way you'd just bind specific samplers to those, say, 16x AF sampler for the first two, normal linear sampler for the third.


This makes texture binding very straightforward, if mesh has diffuse, it gets bound to tex unit 0, if mesh has normal map, gets bound to tex unit 1, and so on. If you want to change the sampling parameters for all common textures, just rebind a sampler to the first texture unit.


Now, this obviously restricts streamlines a lot what you can do, and if you want to go with a configurable rendering pipeline its not a good idea, but I'd just say to trim the corners whenever you can, code not for all the possible things you could do, but for all the possible things you're sure you'll be going to do.