|
Stay the hell away from NeHe's tutorials, they're terrible. Instead, start off with the ones by Nate Robbins, which are drat nice and even mentioned in the OpenGL Red Book. Also, the OpenGL Red Book is recent if you've got one that covers the latest version of OpenGL. Right now OpenGL is at 2.1, with 3.0 coming out "real soon now". I've got the one that covers both 1.5 and 2.0, so mine isn't too out of date. If your Red Book is from the Quake III era, just get a newer, more up-to-date one. Get the OpenGL Orange Book whose version matches the new Red Book you're going to buy If you want to do any sort of semi-advanced graphics at all, get GPU Gems 1, 2, & 3. Also check out the Game Programming Gems series. Use SDL for window creation/handling and input with OpenGL for graphics. It runs on pretty much every platform under the sun, and unlike GLUT it's meant for more than just toy applications. It'll probably be easier to use an existing engine or renderer, though. OGRE and Horde3D seem like decent open-source renderers. There's also Open Scene Graph. When it comes to closed-source engines, there's always Torque, but I don't know how well that runs on Linux these days.
|
# ¿ Nov 24, 2007 09:17 |
|
|
# ¿ Apr 27, 2024 23:46 |
|
Look for a library that can load the image type you need. Of course, I'm not aware of there being one just for BMP. Try something like DevIL or SDL_image (requires use of SDL), both of which can handle multiple image formats (probably including BMP). Or visit wotsit.org, look up the BMP file format, and write your own loader. BMP files are fairly simple if memory serves, so writing a loader shouldn't be too hard.
|
# ¿ Dec 1, 2007 10:36 |
|
vanjalolz posted:I looked at the Nate Robbins tutorials, and although they are really funky, they clearly target a different crowd. NeHe teaches you OpenGL from the ground up, Nate Robbins shows you how the parameters of a function call come together. OpenGL colour books are equally sucky at walking you through step by step. Great reference, terrible point to start. I tried learning from NeHe, and failed miserably. The problem I was having is that NeHe doesn't teach any of the reasons why the code does what it does. And the code itself is horrible, which just made it worse. So I bought the Red Book and learned OpenGL from that. It starts you off at the basics, making sure you understand the pipeline and what's going on under the hood. NeHe does none of that, and is mostly a "copy-paste without really understanding what's going on" type of site IMHO.
|
# ¿ Dec 2, 2007 04:37 |
|
Yeah, just use framebuffer objects. They're similar to the render-to-texture extension and pbuffers, but are faster and easier to use. So, basically, you set up an FBO with appropriately sized textures (one for the background layer, one for the foreground) attached as color attachments. You render whatever into the background "layer", then render something into the foreground "layer". Then you bind to FBO 0 (the default framebuffer provided by the window system), bind a shader with the foreground and background "layers" as texture samplers, and render a quad that covers the screen. The shader then performs whatever blending operation you want. This is basically how post-processing effects in games are done.
|
# ¿ Dec 7, 2007 04:17 |
|
What's wrong with FBOs?
|
# ¿ Dec 7, 2007 09:14 |
|
Again, use FBOs. Set up an FBO with two color attachments. Render Step 1 into color attachment 0. Switch to color attachment 1 and, using color attachment 0 as a texture, render a quad that covers the screen using a shader that just puts the red channel into the alpha channel. Then, when rendering Step 3, use color attachment 1 as one of the textures, with a shader that uses color attachment 1's alpha as its own. But that's the complicated way of doing it. The simpler way would be to set up an FBO with only one color attachment, render Step 1 into it, then switch back to the default FBO, and render Step 3 using a shader that takes in your FBO's color attachment as a texture and uses its Red channel as alpha. Either method should be faster than the way you outlined since you'll only be rendering the scene from Step 1 once instead of twice. Also, you do know that on modern hardware the fixed-function pipeline is just emulated, right? So using a well-optimized shader shouldn't be any slower than the "fixed-function" shaders that the driver loads. In fact, in either the upcoming version of OpenGL or the one after it all the fixed-function emulation is going to be removed.
|
# ¿ Dec 7, 2007 21:38 |
|
Glad I could help. But in return you have to tell us more about your program.
|
# ¿ Dec 8, 2007 03:50 |
|
In all fairness, that stuff (and what you're supposed to do) is explained in the tutorial.
|
# ¿ Dec 9, 2007 07:23 |
|
Does anybody know how far back ATI hardware supports FBOs and non-power-of-two textures (or at least texture rectangles)?
|
# ¿ Dec 18, 2007 11:46 |
|
Awesome, thanks. Looks like I'm going to have to use texture rectangles instead of NPOT textures, though
|
# ¿ Dec 19, 2007 03:23 |
|
HB posted:I think it's something Java3D did. If a graphics card doesn't support rectangular textures then they can't be used in OpenGL, it's an optional extension (at least, it used to be, and rectangular texture support has been present in all 3D cards for the past several generations). There's nothing stopping the driver (for non-NPOT hardware) from claiming NPOT support and then just padding NPOT textures out to POT ones, or doing what Barrackas said, or some other method. Just like drivers could claim FBO support when the underlying hardware doesn't and then just do a copy operation behind the scenes. Texture rectangles are a different beast than NPOT textures, BTW.
|
# ¿ Dec 20, 2007 19:54 |
|
We can't all target Quadros
|
# ¿ Dec 21, 2007 01:42 |
|
Try SQLite, an embedded SQL database. Honestly, though, I don't think you need a full-on database for this. Just simple name value pairs in a text file would probably be enough: code:
|
# ¿ Feb 24, 2008 12:32 |
|
He's talking about 2D sidescrolling terrain with destruction, a la Worms, not 3D terrain. The question was how to do pixel-perfect terrain destruction like in Worms, where a bomb "eats" the terrain, then the terrain collapses. That was answered already. But I think now he's wondering how to actually draw it. Tiling alone isn't enough, since you'd need a tile for each possible way each piece of terrain could be destroyed, which would require a huge amount of video memory, defeating the whole point of tiling in the first place. Honestly, the easiest way is to forgo using the 3D hardware and just do it all via software blitting. Then you can store your whole level as one big image in memory and destroy it as you go. But then you don't get to have pretty explosions, free alpha blending, etc. What I'd do is decide if having the terrain collapse after the bomb eats away at it is necessary. If not, you can still use the 3D hardware as a fast 2D blitter: 1)When an explosion occurs, eat away the terrain in the destruction bitmap. Use the destruction bitmap for collision detection. 2)Save the center point and radius of the explosion in a list. 3)Draw your background 4)Draw explosions (even ones that have already happened) into the stencil buffer. Just draw a circle, using the center point and radius from your list. 5)Draw the terrain using tiling, but with the stencil buffer check turned on. Wherever an explosion has taken place, the terrain won't get drawn. You should probably prune the explosion list periodically, looking for things like one explosion that completely overlaps another, to reduce overdraw in the stencil buffer.
|
# ¿ Mar 6, 2008 23:50 |
|
Right, but just deforming a mesh would look like rear end unless you had a really high resolution mesh. Maybe I'm just misunderstanding...
|
# ¿ Mar 10, 2008 08:09 |
|
Yeah, shaders with a 1D lookup texture for the palette is probably the best way to go.
|
# ¿ Mar 12, 2008 22:08 |
|
If I'm making a game for Windows and Mac, how sorry am I gonna be later on for manually maintaining the Visual Studio and Xcode projects? It feels like I should use CMake or something to generate them, but on the other hand I won't be distributing the source code, so no need for using CMake to make sure whoever is doing the build is using a compiler that supports all the C++11/14 features used, where they have SDL installed, etc. I'm aware that I'll have to update both projects every time I added or removed a file, but most of the development is gonna be done on one platform and then just ported to the other, so that shouldn't happen too often. And it seems like using the CMake-generated project files to do the actual development work would be annoying. Maybe keep a separate project for development and use CMake to generate the build systems for building release binaries? Ideas? Or should I ask this in the C++ megathread? Doc Block fucked around with this message at 21:44 on Dec 29, 2017 |
# ¿ Dec 29, 2017 21:39 |
|
Chainclaw posted:How easy is it to figure out when you make a mistake and forget to add a file to one solution and not the other? If it's difficult and leads to unexpected problems, then that's a point for automation. If it's obvious that something's wrong, and obvious how to fix it, then automation isn't as necessary. I haven't started the game yet, but I'm most likely gonna do all/most of the development on Mac and then port to Windows, since I'm a Mac crybaby and am a lot more familiar with macOS than Windows. So having to mess around with adding/removing/renaming files for both at the same time shouldn't be too big of an issue. OneEightHundred posted:Keep in mind that if you're doing C++ builds on Windows that you expect to be portable to any non-MS platform and you're using templates at all, you need to constantly check that your code is still compiling on that other platform because MS's C++ compiler is extremely over-permissive about parsing identifiers in template code. Thanks, I'll definitely keep this in mind.
|
# ¿ Dec 30, 2017 10:34 |
|
It took me way too long to figure out they renamed Globals to ProjectSettings
|
# ¿ Jan 31, 2018 01:21 |
|
Aww, the grid map node is buggy in Godot 3.0
|
# ¿ Feb 1, 2018 04:26 |
|
deadly_pudding posted:In a sort of belated New Years resolution, I'm gonna finally start buckling down on game dev. I've flirted with it a bit, and made some (bad) games as a teenager. My goal for now is to just start cranking out a ton of dumb tech demos in GameMaker and see if one of them sticks. I realize Unity and UE4 are both things, but it's way easier for me to make my own assets for a 2D game Cool. Also maybe check out Godot, which can do both 2D and 3D, and lets you write your game logic visually, in a friendly scripting language, or in C++ or C# if you prefer. And it’s free, unlike GameMaker.
|
# ¿ Feb 5, 2018 20:01 |
|
beauty queen breakdown posted:Seconding the notes above on Godot 3.0, but adding a question -- Do you mean it doesn't do version control with git? While Godot doesn't handle version control for you, there's nothing stopping you from putting your Godot-based game in version control yourself, including git.
|
# ¿ Apr 17, 2018 07:08 |
|
You can do pretty much everything in code in Godot, it’s just that most people don’t want to.
|
# ¿ Apr 17, 2018 19:06 |
|
Have you watched any of the videos that Unity themselves have put up?
|
# ¿ Apr 22, 2018 20:34 |
|
OneEightHundred posted:The end begins: Apple has deprecated OpenGL on macOS. Meh. OpenGL has been dying for a long time across the board. It's been effectively dead on iOS since Metal was introduced. People should've seen the writing on the wall for OpenGL on macOS as soon as Metal was brought over from iOS. I mean, hell, Apple didn't update OpenGL at all for the previous macOS release, opting instead to leave it at OpenGL 4.1. My main system, a 2011 iMac, is too old for Metal (and too old for the upcoming macOS 10.14) which is a real bummer, but even I'm not mad about it and knew this was coming sooner or later. At least Metal is a nice API.
|
# ¿ Jun 6, 2018 07:56 |
|
Jewel posted:For what it's worth, Celeste's had 2.5% of total sales on mac, and its most likely mirrored across the board . It doesn't seem worth it to take the time to port to metal. This is going to bite the game market bad I think. If you already have support for multiple graphics APIs, adding a Metal backend isn’t an impossible amount of work. edit: and games running on Unity and Unreal already have Metal support. Doc Block fucked around with this message at 14:17 on Jun 6, 2018 |
# ¿ Jun 6, 2018 14:14 |
|
Did anyone actually think Vulkan was ever going to come to macOS or iOS?
|
# ¿ Jun 6, 2018 15:47 |
|
They’re already doing their own GPUs. The A11 used in the iPhone 8, iPhone X, etc, has an Apple-designed GPU.
|
# ¿ Jun 6, 2018 17:36 |
|
At first they used PowerVR designs, then they used customized PowerVR designs, and now they’re using their own GPU designs starting with the A11. News that Apple would no longer be a PowerVR licensee hurt PowerVR’s owner pretty badly.
|
# ¿ Jun 6, 2018 18:33 |
|
LOL some dude on Gamasutra wrote a blog post whining about how Epic’s “game launcher” doesn’t have all the features Steam does, and since on a bullet point comparison it comes up short it’s gonna fail. Never mind that 90% of the “features” in Steam are garbage, added in a haphazard, fling-poo poo-at-the-wall-and-see-what-sticks directionless style, and probably only get used by a tiny fraction of users.
|
# ¿ Dec 13, 2018 03:51 |
|
Remember when GitLab lost something like a week+ of everyone’s commits etc because they didn’t know what the gently caress they were doing and their backups were hosed as well?
|
# ¿ Jan 8, 2019 19:22 |
|
roomforthetuna posted:If so, alternative suggestion, a handful of scripts that do only the operations that artists should be doing, so they don't need to care about the dangers of git. Yeah, this. Why let people who don’t have enough technical knowledge to use git properly use it directly in the first place? Script or artist-friendly front ends seem like the solution, not choosing a VCS based on how hard it is for artists to mess up.
|
# ¿ Jan 19, 2019 21:02 |
|
Also if it really is necessary you could always just pre-compute the collision polygons, or use something like Physics Editor.
|
# ¿ Feb 8, 2019 04:23 |
|
Maybe determine where on the textured quad you’re hitting, and use the UV coords of the hit to do a check against precomputed 2D collision shapes like you would in a 2D game? Since they’re precomputed, keeping a different set for each animation frame shouldn’t be that big of a deal, and since you aren’t hit testing them in 3D it should be fast (just testing if the hit point UV coord is inside any of the current frame’s 2D collision shapes).
|
# ¿ Feb 8, 2019 08:02 |
|
Mooey Cow posted:You'll want to keep the texture data in main memory though; if you have to download it from graphics memory it will not necessarily be very fast. A copy of it, yes. Also, a check to see if a 2D point is inside a handful of 2D collision shapes is incredibly fast, and gives you the option of being selective about what non-transparent pixels count as a hit, so you can exclude hair or a cape or a glow effect or whatever.
|
# ¿ Feb 8, 2019 19:45 |
|
So I'm making a 2D game, and for part of it I want to have one of those cheesy 80s laser grid backgrounds. Easy enough to draw, buuuut I'd like it to be animated programatically. And this is a 2D engine, so I can't just drop in a 3D grid model and call it good. Trying to do something like this, and have the horizontal lines move downwards over time to make it look like the player is moving forward. Drawing horizontal lines further and further downward over time is easy enough, but it doesn't look right since there's no perspective/foreshortening; the lines stay the same distance apart the whole time so it looks wrong. So that's my question: can anyone point me in the right direction regarding figuring out how to spread the lines out as they move downward so they look right? Something simpler than generating a 3D grid at runtime and doing the matrix math myself (no 3D engine underneath)? edit: I feel like the solution involves Pythagoras' theorem somehow, but I just can't seem to put it all together. Can you tell I'm bad at math? Doc Block fucked around with this message at 20:18 on Apr 20, 2019 |
# ¿ Apr 20, 2019 20:13 |
|
Thx for the link. I haven't done any 3D math in a long time, so we'll see how long it takes my stupid brain to relearn all this stuff.
|
# ¿ Apr 20, 2019 21:52 |
|
KillHour posted:Moving the horizontal lines down is the easiest way to go here. You're close in that you want trigonometry, but Pythagoras isn't quite right. You want the inverse tangent (arctan) of camera height/distance. That will give you the angle down from the camera's forward direction. Yes, this is exactly what I needed. Thank you!
|
# ¿ Apr 21, 2019 01:53 |
|
Yeah it needs some sort of GUI with a bunch of sliders so I can dial in juuuust the right look and then use it in the actual game.
|
# ¿ Apr 21, 2019 02:16 |
|
|
# ¿ Apr 27, 2024 23:46 |
|
I don’t recall a video. But there was a blog post where somebody hooked RenderDoc up to it and went super in depth about what it takes to render a single frame. IIRC they had also done it for PC GTA 5. Here it is edit: gently caress; beaten
|
# ¿ Jul 18, 2019 00:53 |