Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Doc Block
Apr 15, 2003
Fun Shoe
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.

Adbot
ADBOT LOVES YOU

Doc Block
Apr 15, 2003
Fun Shoe
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.

Doc Block
Apr 15, 2003
Fun Shoe

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.

As for the BMP loading, code stealing is the best way, but if you're stealing code you may as well steal something that doesn't completely suck. PNG is cool, but libpng is a dependency that I really can't be bothered with.

Here is a TGA loader I found on the net somewhere:

http://pastebin.com/f7c2b44e2

http://rapidshare.com/files/73582942/tga.rar.html

Just call it with
GLuint tex = loadTGATexture(filename)
or set a texid your self loadTGATexture(filename,texid)

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.

Doc Block
Apr 15, 2003
Fun Shoe
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.

Doc Block
Apr 15, 2003
Fun Shoe
What's wrong with FBOs?

Doc Block
Apr 15, 2003
Fun Shoe
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.

Doc Block
Apr 15, 2003
Fun Shoe
Glad I could help.

But in return you have to tell us more about your program.

Doc Block
Apr 15, 2003
Fun Shoe
In all fairness, that stuff (and what you're supposed to do) is explained in the tutorial.

Doc Block
Apr 15, 2003
Fun Shoe
Does anybody know how far back ATI hardware supports FBOs and non-power-of-two textures (or at least texture rectangles)?

Doc Block
Apr 15, 2003
Fun Shoe
Awesome, thanks.

Looks like I'm going to have to use texture rectangles instead of NPOT textures, though :(

Doc Block
Apr 15, 2003
Fun Shoe

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.

Doc Block
Apr 15, 2003
Fun Shoe
We can't all target Quadros :argh:

Doc Block
Apr 15, 2003
Fun Shoe
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:
npc37_string1 = "Why, hello there traveller!"
npc37_string2 = "No, I don't have any of those..."
Load the strings into a hash map, and from there on refer to them by name (show_dialog(your_string_hash_map["npc37_string1"]). Plus, it'll make internationalization easier if you ever need to.

Doc Block
Apr 15, 2003
Fun Shoe
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.

Doc Block
Apr 15, 2003
Fun Shoe
Right, but just deforming a mesh would look like rear end unless you had a really high resolution mesh.

Maybe I'm just misunderstanding...

Doc Block
Apr 15, 2003
Fun Shoe
Yeah, shaders with a 1D lookup texture for the palette is probably the best way to go.

Doc Block
Apr 15, 2003
Fun Shoe
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

Doc Block
Apr 15, 2003
Fun Shoe

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.

How much time are you spending maintaining those solutions right now? How many files do you add day to day? If you're adding a ton, then the automation investment is worth it.

How often do you avoid making new C++ files and instead shove stuff into existing files, even when it doesn't make sense or kind of breaks your standard? If you're not creating new files as often as you should, then it might be because you've made it difficult to create new files and you're avoiding updating those solutions.

Autogenerated solutions and projects are great when done correctly. It is easy to gently caress up the automation, and it's also easy to go down a bad rabbit hole and spend way more time on an automated solution than you end up saving.

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.

Doc Block
Apr 15, 2003
Fun Shoe

:woop:

It took me way too long to figure out they renamed Globals to ProjectSettings

Doc Block
Apr 15, 2003
Fun Shoe
Aww, the grid map node is buggy in Godot 3.0 :argh:

Doc Block
Apr 15, 2003
Fun Shoe

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 :v:

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.

Doc Block
Apr 15, 2003
Fun Shoe

beauty queen breakdown posted:

Seconding the notes above on Godot 3.0, but adding a question --

Coming from an enterprise perspective, I've found Godot doesn't die to version control with `git`, but there's still a lot of point-click-&c in the interface. As an impatient person, this drives me crazy but I'm trying to stick with it on the basis of cross-platform dev on the quick.

I really want to use something like libGDX where I can develop a game on the JVM, but I've found virtually no tooling support for builds / getting started -- the docs are a mishmash of what they were doing a few years ago with maven and doing now with gradle...

Am I the only person with this kind of thought process? Am I terrible? I have to presume so.


( edit : I'm only interested in 2D development in this context )

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.

Doc Block
Apr 15, 2003
Fun Shoe
You can do pretty much everything in code in Godot, it’s just that most people don’t want to.

Doc Block
Apr 15, 2003
Fun Shoe
Have you watched any of the videos that Unity themselves have put up?

Doc Block
Apr 15, 2003
Fun Shoe

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.

Doc Block
Apr 15, 2003
Fun Shoe

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.

96.3% of steam users are on windows, 3% on mac, 0.6% on linux.

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

Doc Block
Apr 15, 2003
Fun Shoe
Did anyone actually think Vulkan was ever going to come to macOS or iOS?

Doc Block
Apr 15, 2003
Fun Shoe
They’re already doing their own GPUs. The A11 used in the iPhone 8, iPhone X, etc, has an Apple-designed GPU.

Doc Block
Apr 15, 2003
Fun Shoe
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.

Doc Block
Apr 15, 2003
Fun Shoe
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.

Doc Block
Apr 15, 2003
Fun Shoe
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? :laugh:

Doc Block
Apr 15, 2003
Fun Shoe

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.

Doc Block
Apr 15, 2003
Fun Shoe
Also if it really is necessary you could always just pre-compute the collision polygons, or use something like Physics Editor.

Doc Block
Apr 15, 2003
Fun Shoe
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).

Doc Block
Apr 15, 2003
Fun Shoe

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.

Doc Block
Apr 15, 2003
Fun Shoe
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

Doc Block
Apr 15, 2003
Fun Shoe
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.

Doc Block
Apr 15, 2003
Fun Shoe

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.

For instance, if you want to have a horizontal grid line every 10 ft and your camera's height off the ground is 6 ft, your first few lines would be:

tan-1(6/10) ≈ 30°
tan-1(6/20) ≈ 17°
tan-1(6/30) ≈ 11°
tan-1(6/40) ≈ 9°

Now, since you're drawing this on an orthographic camera instead of a perspective camera, you need this to be projected on a flat surface. Easy to do - just use trig again. This time we're going to use tangent because we're going from an angle to a scalar ratio. tan(30°) gives you ≈ 0.58, which is your opposite over adjacent (height over distance). We have a fixed distance to the projected surface, (you'll have to play around with it to get the right scale, but let's call it 10), so you just multiply by that distance to give you your height (5.8 of whatever units you're working in). This is distance below the horizon, remember.

Now wait, tan and arctan are inverses of each other, so taking the tangent of the inverse tangent just gives you the same thing you started with, and you can simplify to just the following:

lineOffset = cameraHeight / (i * lineDistance) * cameraDistance

I wrote a quick program in C# to show the concept.

code:
using System;

namespace Line_Draw_Test_CS {
	class Program {
		static void Main(string[] args) {
			Console.ForegroundColor = ConsoleColor.White;
			Console.SetWindowSize(400, 200);

			var lineDistance = 10.0;
			var lineCount = 10;
			var unitScale = Console.WindowHeight / 50.0;
			var horizon = 10.0 * unitScale;
			var cameraHeight = 6.0;
			var cameraDistance = 60;
			
			for (var i = 1; i <= lineCount; i++) {
				var lineOffset = cameraHeight / (i * lineDistance) * cameraDistance;
				Console.CursorTop = (int)Math.Round(horizon + (lineOffset * unitScale));
				for (var j = 0; j < Console.WindowWidth; j++) {
					Console.CursorLeft = j;
					Console.Write("_");
				}
			}

			Console.ReadLine();
		}
	}
}


Hope this helps!

Yes, this is exactly what I needed. Thank you!



:hellyeah:

Doc Block
Apr 15, 2003
Fun Shoe
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.

Adbot
ADBOT LOVES YOU

Doc Block
Apr 15, 2003
Fun Shoe
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

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply