IRCLogs • ArmaNelgTron.tk

Searching from 2022-01-04 00:00:00 to 2022-01-04 23:59:59.999999.
Query completed in 8.00 seconds
[2022-01-04 00:17:25] --> Luke-Jr has joined the channel
[2022-01-04 06:25:22] <Z-Man> Immediate Mode GUI works like immediate mode OpenGL. You have no objects representing the UI, just function calls. So a main menu might look like
[2022-01-04 06:25:29] <Z-Man> void MainMenu(){
[2022-01-04 06:25:46] <Z-Man> MenuStart("Main Menu");
[2022-01-04 06:26:10] <Z-Man> if( MenuItemText("Start") ) EnterGame();
[2022-01-04 06:26:43] <Z-Man> if( MenuItemText("Settings") ) SettingsMenu();
[2022-01-04 06:26:55] <Z-Man> if( MenuItemText("Exit")) return;
[2022-01-04 06:27:02] <Z-Man> MenuEnd();
[2022-01-04 06:27:03] <Z-Man> }
[2022-01-04 06:27:22] <Z-Man> And I forgot to put all of that function body into a while(true) loop.
[2022-01-04 06:30:52] <Z-Man> So for each UI item, you pass all the information needed into a function, and the return value tells you the state. It might be more elaborate than a boolean, maybe you can also detect which item currently is selected.
[2022-01-04 06:32:30] <Z-Man> And there usually needs to be some local state; something does need to track which item currently is selected, where the mouse pointer is and things.
[2022-01-04 06:45:45] <Z-Man> The "20 lines or less for any classic game" goal is a good one. If interpreted loosely, yeah. Without any lines that make you go "wtf do *I* have to do this?" might be a better angle, after all, complexity varies. The destructible shield blocks in Space Invaders, for example, would take up a surprising amount of code in any modern reimplementation.
[2022-01-04 06:46:31] <Z-Man> Back then, they were just bits in the framebuffer, I assume, and you'd directly check for collisions by checking the right bit at the location of the shots and clear them out on hit.
[2022-01-04 06:47:33] <Z-Man> Nowadays, you don't have direct cheap access to the frame buffer, or any graphics buffer. So you have to keep a shadow copy in some CPU accessible data structure.
[2022-01-04 06:48:28] <Z-Man> And on hit, you need to update the image and re-upload it to the GPU... Of course, if you're super hardcore, you do it all in shader code that runs entirely on the GPU.
[2022-01-04 06:52:53] <Z-Man> Huh, apparently nobody has done that so far.
[2022-01-04 06:57:01] <Z-Man> Another super important test for any engine: A platformer with moving platforms. Absolutely critical: If you are standing on a platform that moves upward, you must not sink into it.
[2022-01-04 06:59:51] <Z-Man> Movement must not become glitchy on a platform that is moving downward. Even Zelda: BOTW gets this wrong. "Moving" may also mean "Rotating" and you're standing on the side that goes up or down.
[2022-01-04 07:07:12] <Z-Man> Conservation of momentum needs to be a choice for the game designer. If a platform I'm on switches from moving to the left to moving to the right suddenly, do I still move a bit to the left, risking falling off, or do I stay glued to the platform? If I jump off a platform that is moving up, does my jump get higher than usual? If a platform I am on is continuously moving left and I jump up, do I still move left and safely land back on the 
[2022-01-04 07:07:12] <Z-Man> platform without touching the left/right controls (air resistance ignored)? The engine should not answer those questions. So collision information given to the game needs to not just include current positions, but also velocities for this and the previous frame, minimum.
[2022-01-04 07:18:26] <Z-Man> Another thing many platformers have that engines support poorly: One way collisions. Platforms that you don't fall off, but you can jump through them from below. Usually represented as thin floors. Related: Walls you can only pass one way. I can't think of a good unified solution that can handle both.
[2022-01-04 07:33:05] <Z-Man> Game code execution order is critical for all of this. I personally would not use an event based system, given the choice. Handling player input and player movement need to happen together. I can't think of a situation where I would want to subscribe to an input event, all I'd do in the handler is store the input away for later processing.
[2022-01-04 07:35:42] <Z-Man> (So yes, Arma uses a mechanism that passes for event based input processing and pressing a turn key on the client immediately turns the cycle on the client. But STFU :) The brake is just stored in a bit, and on the server, input commands from the clients are just stored in a buffer for later execution.)
[2022-01-04 07:41:36] <Z-Man> Same for collision events. The right time to resolve player collisions is right after you decided how you want to move the player. If collisions are reported via events exclusively, that makes reacting to them correclty hard.
[2022-01-04 07:45:08] <Z-Man> Of course, there a case can be made that collision events should be provided: If I want a ball bouncing around the level, I don't want to check for its collision state every frame. I want it handled by physics. Ideally completely, but if I want to customize its bounce so it never gets to rest, I'll need to put some work in, and a collision event handler would be the most convenient place to do that.
[2022-01-04 11:10:58] <Z-Man> Back to moving platforms, you also want good support for elements that slowly react to the player character's presence, like scales and see-saws that go down when you are on top of them. The quick handwavy solution to all of those is to just stick everything into a physics system. Only then, you make behavior much harder to tune because you're no longer setting the maximum player run speed, you're setting friction, mass and forces. Also, 
[2022-01-04 11:10:58] <Z-Man> you open yourself up to weird, unexplainable glitches.
[2022-01-04 11:13:52] <Z-Man> So slowly reacting stuff needs to be possible without full physics. Should not be a problem, since it's supposed to react slowly, you get away with having it react to the state of the player character a frame ago.
[2022-01-04 11:14:26] <Z-Man> Qt::QGraphicsView does indeed look like a 2D game rendering engine, just one with a lot of stuff you don't need :)
[2022-01-04 11:26:43] <Z-Man> The Wii U has a proprietary RF signal feeding the tablet display, IIRC. Only that gave it a low enough latency. Over IP and especially WiFi, you will always get delays. Of course, for secondary displays or slower stuff, it can still work. There are very few games that use the smartphones everybody is expected to have now as secondary displays.
[2022-01-04 11:27:52] <Z-Man> Fibbage, I think, is a game that uses a big screen for shared information, and then each player's smartphone for secret information... IIRC, it's a "who can lie to the assembled friends best" kind of game.
[2022-01-04 11:28:51] <Z-Man> And I think there is a Starship Bridge Simulator thing like you wanted to create, where the TV is the main viewscreen and every bridge crewmember has their console on their own device.
[2022-01-04 11:29:13] <Z-Man> More of that stuff could be good.
[2022-01-04 13:43:36] --> lukedashjr has joined the channel
[2022-01-04 13:44:03] <-- luke-jr has quit (Ping timeout: 256 seconds)
[2022-01-04 13:45:26] -!- lukedashjr changed nick to luke-jr
[2022-01-04 13:48:32] <-- Luke-Jr has quit (Ping timeout: 480 seconds)
[2022-01-04 13:52:50] --> lukedashjr has joined the channel
[2022-01-04 13:54:37] <-- luke-jr has quit (Ping timeout: 240 seconds)
[2022-01-04 13:54:42] -!- lukedashjr changed nick to luke-jr
[2022-01-04 14:11:53] --> Luke-Jr has joined the channel
[2022-01-04 14:57:01] <-- luke-jr has quit (Ping timeout: 256 seconds)
[2022-01-04 14:58:16] --> luke-jr has joined the channel
[2022-01-04 15:01:00] <-- Luke-Jr has quit (Ping timeout: 480 seconds)
[2022-01-04 15:24:20] --> Luke-Jr has joined the channel
[2022-01-04 17:04:18] <-- Lucifer_arma has quit (Quit: Konversation terminated!)
[2022-01-04 17:33:38] --> Lucifer_arma has joined the channel
[2022-01-04 17:35:24] <Lucifer_arma> EmptyEpsilon is the open source bridge simulator, and it's quite fun
[2022-01-04 17:35:31] <Lucifer_arma> there's also Space Nerds in Space
[2022-01-04 17:41:22] <Lucifer_arma> Event-based collision detection, imo, is most useful for objects that aren't real important and have their own physics embedded in the class
[2022-01-04 17:41:55] <Lucifer_arma> While I want to have everything be event-based, I don't want event-based to be everything.  So there will always be a second way to do something besides events
[2022-01-04 17:42:38] <Lucifer_arma> sometimes a third.  Usually, lots of ways because the mechanism I want to use is to simply expose the fundamentals for the programmer, where game engines usually go out of their way to hide the fundamentals
[2022-01-04 17:43:42] <Lucifer_arma> also, I've seen an issue with people writing games using event-based input.  It's most obvious in Rocks and Diamonds, where two player is unplayable because their event handlers are mutually exclusive
[2022-01-04 17:44:24] <Lucifer_arma> the good news is that a decent compiler won't even include event code that's not used in the binary
[2022-01-04 17:49:04] <Lucifer_arma> You're also sorta describing a modal dialog in your immediate mode gui.  I don't have any intention of supporting that pattern, sorry.  You'll get roughly the same effect in what I do write, but it'll be different in a few ways
[2022-01-04 17:49:35] <Lucifer_arma> as for the Wii U's dumb controller, it was dumb in how they implemented it.  They already use bluetooth to connect wirelessly, but they made the screen dumb
[2022-01-04 17:50:06] <Lucifer_arma> we'll have an actual android client that you install to be the controller, so the only data sent over the wire will be game data in small amounts, and keeping *that* low latency is pretty easy
[2022-01-04 17:51:28] <Lucifer_arma> and yeah, moving platforms are one of the things you have to get right in a platformer.  Blobwars gets them exactly right, I think.
[2022-01-04 17:52:28] <Lucifer_arma> ah, QGraphicsView isn't designed to be a game engine, it's just advanced enough you could use it as one
[2022-01-04 17:52:51] <Lucifer_arma> I think someone has a Qt game engine, but it's poorly maintained, incomplete, and platform support is small
[2022-01-04 17:53:33] <Lucifer_arma> but you could somewhat easily write a QGameView that inherits QGraphicsView that essentially strips away the stuff that's not needed for games
[2022-01-04 17:54:29] <Lucifer_arma> I've been thinking about the space invader shields.  Iirc, on the atari 2600, they didn't even have access to the framebuffer, they had more direct access, which made programming for the system particular hard
[2022-01-04 17:55:30] <Lucifer_arma> I don't have a ready, obvious solution to the space invader shields, let alone a general purpose solution, but I also have a hard time coming up with another game where they did something similar
[2022-01-04 17:56:37] <Lucifer_arma> we're also only using SDL's 2d hardware accelerated api for 2d stuff.  I don't see a reason a new game engine shouldn't be fully hardware accelerated from the start, and SDL will fall back to a decent software renderer if it needs to
[2022-01-04 17:59:09] <Lucifer_arma> we may wind up changing that to an OpenGLES 2d api and not even using SDL's 2d api.  Again, no reason a new game engine should even waste time on software rendering when all the current common devices have OpenGLES drivers
[2022-01-04 17:59:52] <Lucifer_arma> the big change there will be when it's time to support the XBox, which I'm pretty sure doesn't have OpenGL-anything on it, and we'll need a native backend specific for Windows and XBox
[2022-01-04 18:00:00] <Lucifer_arma> so that's obviously down the road quite a bit
[2022-01-04 18:01:36] <Lucifer_arma> so we already have Surface, Sprite, and we'll be adding GameObject to the api
[2022-01-04 18:02:07] <Lucifer_arma> there'll be base classes so these objects can be managed internally regardless of if you're doing 2d or 3d, so in 3d, Surface may become a Mesh or Model
[2022-01-04 18:02:47] <Lucifer_arma> anyway, Surface knows only screen and image coordinates.  Sprite knows screen coordinates and collisions, and game coordinates, and GameObjects will only know game coordinates and collisions
[2022-01-04 18:03:38] <Lucifer_arma> so a sidescroller engine has the same three layer setup, where it'll use Surface to render most things, Sprites for some things, and GameObjects for the player and enemies and stuff
[2022-01-04 18:04:03] <Lucifer_arma> so we'll start with the Surface layer and get that working right and general purpose, because that's where most of the rendering will be happening
[2022-01-04 18:04:52] <Lucifer_arma> then we'll add Sprites, and finally GameObjects, trying to keep in mind that a sidescroller isn't necessarily a platformer.  The same renderer that gives you Super Mario Brothers can also give you Ultima, after all
[2022-01-04 18:06:55] <Lucifer_arma> oh yeah, Sprites also know animation and GameObjects don't need to know.  So those two need to be pretty tightly linked so the Sprite can determine from the GameObject which animation to use without the GameObject even knowing that animation is a thing
[2022-01-04 21:34:40] -!- Z-Man changed nick to Guest10299
[2022-01-04 21:34:43] --> Z-Man has joined the channel
[2022-01-04 21:38:17] <-- Z-Man has quit (Ping timeout: 240 seconds)
[2022-01-04 21:39:50] --> Z-Man has joined the channel
[2022-01-04 21:42:10] <-- Guest10299 has quit (Ping timeout: 480 seconds)
View entire month
DISCLAIMER: These logs of public chat may contain some content which may not be appropriate for all audiences. Use at your own risk.
Logs from 2006-2009 pulled from wrtlprnft
Format changes at: 2015-08-25, 2017-02-20, and 2020-03-23. Times (2015 and later) should be Eastern.
. [About this site] [Credits]