4 ms·

Speaking as someone who has no knowledge of game programming why is raycasting implemented as a light speed traveling thing? Could they have not done the travel

Speaking as someone who has no knowledge of game programming why is raycasting implemented as a light speed traveling thing? Could they have not done the travel computations on a local buffer and add the effects of gravity or other components and then composite he resultant and rendered to screen? Why does it have to be real time? Too memory hungry for that?

rriepe 7y ago
I think you're confusing raycasting with hitscan. They're very similar. Hitscan does that light-speed-line thing you're describing and instantly delivers a "bullet" along it. Raycasting instead takes the light-speed-line information and runs some process like "What could we do to make this play out convincingly?" Then based on that information, it adds the gravity effects and other stuff to what plays out. You might raycast right before a jump to determine what landing animation your player will ultimately use. That's important during the jump because it makes it look more convincing.
friendlybus 7y ago
Raycasts are cheap because they are just two points with an implied line between. Projectiles are great because they are a basic shape inserted into your preexisting physics sim that handles realistic looking gravity and collisions with everything else that has a collision shape. You could have projectiles ricochet off each other. Precomputing a trajectory loses the dynamics of collision and the cheapness of rays. Fixing projected actions into the future from one point in time can make for weird lag effects and unpredictable results for the player when a moveable piece interrupts a fixed bullet path.
meheleventyone 7y ago
Rays are just a geometric primitive defined by a starting point and a direction. So a single raycast based weapon can conceptually fire infinitely far in a single test, so much faster than the speed of light. Collision tests are just the result of calculating the point of intersection between it and other primitives. Games run in discreet time steps called frames or ticks. Bullets travel can then be simulated in several ways for example using numerical integration to apply forces to each bullet for the time step to calculate its new position, collision testing the line segment (“raycasting”) between the position of the last frame and the new position and calculating and displaying the results.
egypturnash 7y ago
Imagine it is 1992. You have an 80286 and a 256-color framebuffer. You need to fill that buffer with a new frame at least every 100ms to have any hope of having something like "an action game" instead of "a vaguely interactive slideshow". You have spent the past month or three writing and optimizing some very slick code that draws a first-person view of a maze, with textured walls and floors. Everyone's jaws drop when you show it to them. It takes about 75-90ms to draw a frame on that 80286. You have next to no time left to run game logic in. Simulating a handful of active enemies and processing player inputs pretty much eat up the rest of the time. But you have this raycasting routine that you optimized the hell out of because it's in the middle of one of the hottest parts of the display-rendering code. So you reuse that as your "is the player aimed at an enemy when they clicked" check. It's good enough, especially since the game's largely set in a tight labyrinth with few spaces large enough that a more realistically simulated bullet wouldn't get to your target in the time between one frame and the next anyway. When you upgrade your view renderer to handle non-grid-aligned walls and arbitrary heights for your next game, you don't bother simulating better bullets. It's still Good Enough - you're targeting a faster CPU now but you're still doing all the rendering yourself because GPUs don't even exist yet, and your rendering is more complicated now and you still only have about 5% of the CPU time left for game logic. You start licensing your view renderer to other game companies. ("You", in this story, are pretty much John Romero.) Other people start writing similar game engines but they make similar decisions for similar reasons; "realistic bullet physics" would be nice to have but that's a lot less impressive than "this game can actually render objects with a triple-digit number of polygons while maintaining a decent framerate and resolution". This situation persists for quite some time until "3D accelerator cards" become something you can expect the average computer owner to have, and you can start spending CPU time on "simulating a more complex world". (It is also worth noting that 2D games written in this timeframe would generally show bullets as visible objects with an exaggeratedly slow travel time, so the player had a chance to dodge them. Rendering 2D stuff is a lot cheaper.)
- hyperman1 7y ago
  For Wolf3D, the player was the only one using full hitscan. Enemies simply decided hit or not based on a dice throw, adjusted with distance to player. Worked well enough until you start noticing they shoot trough almost-closed doors, eaxh other, etc... Doom did a lot better, hence the monster infighting
Impossible 7y ago
Generally speaking it feels better and makes for better gameplay, even if that gameplay is unrealistic. Most games have projectile weapons that have some lead time so there isn't much of a performance reason. HN users tend to think deeper/more complex simulation is directly correlated to better gameplay (see the sword conversation above), but one of the interesting things about games is abstraction. That said more simulation focused games with larger maps (some Battlefield games, ARMA) have bullets with travel velocities and bullet drop.

rriepe 7y ago

I think you're confusing raycasting with hitscan. They're very similar. Hitscan does that light-speed-line thing you're describing and instantly delivers a "bullet" along it. Raycasting instead takes the light-speed-line information and runs some process like "What could we do to make this play out convincingly?" Then based on that information, it adds the gravity effects and other stuff to what plays out. You might raycast right before a jump to determine what landing animation your player will ultimately use. That's important during the jump because it makes it look more convincing.

friendlybus 7y ago

Raycasts are cheap because they are just two points with an implied line between. Projectiles are great because they are a basic shape inserted into your preexisting physics sim that handles realistic looking gravity and collisions with everything else that has a collision shape. You could have projectiles ricochet off each other. Precomputing a trajectory loses the dynamics of collision and the cheapness of rays. Fixing projected actions into the future from one point in time can make for weird lag effects and unpredictable results for the player when a moveable piece interrupts a fixed bullet path.

meheleventyone 7y ago

Rays are just a geometric primitive defined by a starting point and a direction. So a single raycast based weapon can conceptually fire infinitely far in a single test, so much faster than the speed of light. Collision tests are just the result of calculating the point of intersection between it and other primitives. Games run in discreet time steps called frames or ticks. Bullets travel can then be simulated in several ways for example using numerical integration to apply forces to each bullet for the time step to calculate its new position, collision testing the line segment (“raycasting”) between the position of the last frame and the new position and calculating and displaying the results.

egypturnash 7y ago

Imagine it is 1992. You have an 80286 and a 256-color framebuffer. You need to fill that buffer with a new frame at least every 100ms to have any hope of having something like "an action game" instead of "a vaguely interactive slideshow". You have spent the past month or three writing and optimizing some very slick code that draws a first-person view of a maze, with textured walls and floors. Everyone's jaws drop when you show it to them. It takes about 75-90ms to draw a frame on that 80286. You have next to no time left to run game logic in. Simulating a handful of active enemies and processing player inputs pretty much eat up the rest of the time. But you have this raycasting routine that you optimized the hell out of because it's in the middle of one of the hottest parts of the display-rendering code. So you reuse that as your "is the player aimed at an enemy when they clicked" check. It's good enough, especially since the game's largely set in a tight labyrinth with few spaces large enough that a more realistically simulated bullet wouldn't get to your target in the time between one frame and the next anyway. When you upgrade your view renderer to handle non-grid-aligned walls and arbitrary heights for your next game, you don't bother simulating better bullets. It's still Good Enough - you're targeting a faster CPU now but you're still doing all the rendering yourself because GPUs don't even exist yet, and your rendering is more complicated now and you still only have about 5% of the CPU time left for game logic. You start licensing your view renderer to other game companies. ("You", in this story, are pretty much John Romero.) Other people start writing similar game engines but they make similar decisions for similar reasons; "realistic bullet physics" would be nice to have but that's a lot less impressive than "this game can actually render objects with a triple-digit number of polygons while maintaining a decent framerate and resolution". This situation persists for quite some time until "3D accelerator cards" become something you can expect the average computer owner to have, and you can start spending CPU time on "simulating a more complex world". (It is also worth noting that 2D games written in this timeframe would generally show bullets as visible objects with an exaggeratedly slow travel time, so the player had a chance to dodge them. Rendering 2D stuff is a lot cheaper.)

hyperman1 7y ago
For Wolf3D, the player was the only one using full hitscan. Enemies simply decided hit or not based on a dice throw, adjusted with distance to player. Worked well enough until you start noticing they shoot trough almost-closed doors, eaxh other, etc... Doom did a lot better, hence the monster infighting

Impossible 7y ago

Generally speaking it feels better and makes for better gameplay, even if that gameplay is unrealistic. Most games have projectile weapons that have some lead time so there isn't much of a performance reason. HN users tend to think deeper/more complex simulation is directly correlated to better gameplay (see the sword conversation above), but one of the interesting things about games is abstraction. That said more simulation focused games with larger maps (some Battlefield games, ARMA) have bullets with travel velocities and bullet drop.