Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Feb 2007
Offline Last Active Today, 07:53 PM

Posts I've Made

In Topic: Drawing graphics in C++ w/out APIs?

07 October 2015 - 07:13 PM

In the interest of fairness I would like to point out that devices that use port-mapped i/o can't be accessed from pure C/C++ - that requires platform- and compiler-specific extensions.


Fair point. The first by definition, and the second as a matter of C and C++ not defining port-mapped i/o in its abstract machine -- but still, I took OP's intent as "without intervening APIs or drivers; possibly bare-metal", not "100% standard C++: portable and cross-platform." 

In Topic: Drawing graphics in C++ w/out APIs?

07 October 2015 - 11:27 AM

Without an OS getting in the way, talking to hardware still requires poking interrupt handlers and hardware registers and DMA transfers and so on, none of which can be done with pure C++.


Well, that's not quite true. You certainly *could* do those things if you had access to (and understood) the bare-metal. Its true of course that going through at least a BIOS is common and more than enough "to the metal" for most everyone's tastes, but there's nothing inherently special about a BIOS; its just machine code implementing an abstraction layer over the barest of hardware. All those interrupt handlers and hardware registers, including those that control DMA, can be reached from the CPU, so I don't understand how that would prohibit C++.


Agreed, though, that its entirely impractical to attempt talking to modern hardware and getting modern features out of it. If that's your hobby, take up driver development, but even that's done at a substantially higher level of abstraction (with the OS providing IOCTL interfaces and other necessary or useful primitives).

In Topic: Drawing graphics in C++ w/out APIs?

06 October 2015 - 07:28 PM

You can write a software rasterizer -- basically you create a region in memory that's an array of pixels, and then you write your own individual pixels into it. When you're finished, you can use you host's windowing system to display it, or you can shuffle it off to OpenGL/Direct3D through the usual layers, but not using any of their drawing routines. In the old days of DOS that's how graphics were done, except DOS was single user so you could take direct ownership of the graphics adapter's memory and write straight into it.


Drawing pixels, lines, circles, elipses, and bitmaps this way is pretty typical of a 100-level course in computer graphics. A 150 or 200-level course often extends this to 3D, where you first transform the 3D geometry in a software rendering pipeline, and then you rasterize shaded and texture-mapped triangles to the bitmap.


On most platforms you can't easily talk directly to the GPU, and GPU vendors aren't terribly open about their drivers' API surfaces or hardware command registers (Though, they've started being more open lately with the call for open-source drivers) and even if they were you're talking about 2000 pages or more of datasheet to get your head around.


If you want to talk directly to a GPU, your best bet would be something like the DreamCast or Raspberry Pi, but understand that even those "simpler" systems are vastly complicated, and the act of talking to them at a low level doesn't look much like graphics programming, if that's the part that interests you.

In Topic: Using a physics engine on the server

06 October 2015 - 06:57 PM

This reminds me of a statement i once read in an internet RFC (request for comments) document:
Be permissive in what you accept, but strict in what you send.

This statement holds true in any protocol including games.


Sure -- actually, a good application of that mantra would be something like "Clients and servers should be able to deal with bad data (corrupted, maliciously crafted), and send only good data". For example, when I said earlier that the client shouldn't ask the server to move through a wall, the server should never trust a client not to do so -- lots of hacks for different games involve sending messages to the server that are deliberately misleading -- the server needs to validate what the client attempts to do. On the flip side, non-compromised clients -- and especially the server -- should be very strict about what they send and how its sent (for example, don't just let unused bits/bytes in a message be sent out uninitialized).


[Edited to add] Defending against malicious packets is super important. If you recall the Heartbleed security vulnerability from a couple years ago or so, that was a maliciously-crafted packet where the client requested a response longer than it knew the data to be, and the server simply trusted the client to be honest, though I don't believe it was intentional -- more of a logic bug. Bad idea in any event, this compromised tons of services of all sizes -- webmail, banking, Facebook even, IIRC... I remember changing basically all of my passwords because of it. 

In Topic: Using a physics engine on the server

06 October 2015 - 02:51 PM

I'm not really equipped to give low-level advice on the topic, but from a higher level, I find it useful to think of the client as a kind of "smart terminal" into the game as the server sees it -- the client is neither the game, nor is it a "dumb terminal" which only sends keystrokes and renders what the server last told it to.


The client is a "smart terminal" because it handles on its own the things that either don't matter for simulation consistency between player clients, or which can be initialized once by the server and then left to run in a way that will remain consistent -- for example, debris/decals/particle effects can fall into either of these categories depending on whether they are purely cosmetic or have an affect on gameplay. Another reason is that the client must make it's best-guess about the current state of the simulation between messages from the server, as a basic example, you might render at 60 frames per second, but you might only get network updates at 10, 15, or 20 times per second (and each of which might have between one-half and several frames of latency by the time you receive it) -- So when a projectile or player is last known to be moving in a given direction, the client has to assume it keeps doing so, but also smoothly interpolate back inline with what the server says to be true when it receives the next relevant message. Similarly, for things like collision detection, the client can know that its impossible to walk through a wall and so should not permit the player to do so while waiting for the server to reprimand it, nor should it even ask the server whether its possible. In short, the client should be smart enough to give its best estimate of what the server will say to be true, based on its imperfect information, and be able to get back in line by smoothly integrating the latest authoritative information from the server.