Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 08 Apr 2011
Offline Last Active Today, 04:07 PM

#5231215 Graphics engines: what's more common; standard vertex structure or dynami...

Posted by axefrog on Today, 05:46 AM

What's more common in engines? Using a standard one-size-fits-all vertex structure, or a custom vertex structure depending on the context, and delegating the choice of vertex composition, and associated shader input layouts, to the game developer? Is there any significant downside to hardcoding a standard vertex structure? Is vertex structure flexibility a case of YAGNI?

#5230831 In HLSL, multiplying a position by an identity matrix is screwing up the posi...

Posted by axefrog on 25 May 2015 - 07:13 AM

Ah! Thanks, yep that did it.

Now to go back to debugging the original problem tongue.png

#5230737 The plan...

Posted by axefrog on 24 May 2015 - 04:44 PM

I like OneNote myself. It's free, and it syncs. And you can type, paste pictures and web clippings, and draw on it with a tablet.

#5230154 How do they get games to open themselves?

Posted by axefrog on 20 May 2015 - 06:13 PM

I suspect it would have been a secondary process, probably the game's updater software that did it. If the game can launch the updater, and the updater can launch the game, then you can easily have one shut the other down, update it and then relaunch it. Sometimes a game is set to relaunch itself but you "intervene" and close the game prematurely. This doesn't stop the updater software from observing that the process terminated and taking that to mean that it's ok to restart it.

#5230151 Were do I start learning computer science?

Posted by axefrog on 20 May 2015 - 06:05 PM

The best way to learn is always hands-on, but beware: Once you start programming there is no turning back. You quickly find it much more fun than designing and you get hooked. Hooked on the raw power and freedom you have gained. You grow 5 inches taller and your hair turns blonde and you get a tan, and public-nudity laws in your country or state are suspended just for you. The women won't leave you alone and you instantly become a millionaire.

Be warned. It happened to all of us.

Yep, listen to L. Spiro. He knows what he's talking about. The power to create whatever you want turns you into an invincible super-powered creation machine. Imagine it and you can make it. I can think of no other profession that gives you that level of power. If you don't want to go to university, check out Khan Academy. There are a bunch of computer science topics there. I consider mathematics a part of computer science as well, and Khan Academy has you covered there as well.

#5230144 Signed-Distance Field Font

Posted by axefrog on 20 May 2015 - 05:42 PM

You need to generate the glyph at a really large size, calculate the distance field and then scale down. In Valve's paper I think they do it at 4096x4096 pixels, or something like that. I was having exactly the same problem as you until I generated the glyph at a huge size, performed the distance field calculation at *that* size, and then scaled down. Then suddenly everything started rendering nicely. Note that the edge threshold value still needs to be adjusted depending on the size you render at.

#5218694 C#

Posted by axefrog on 24 March 2015 - 12:19 AM

2) c# basically is for microsoft and only works for microsoft platforms.

Man, I wish people would stop spouting this outdated nonsense. C# is an open standard, and as others have said, Mono/Xamarin have been around for ages now and they let you target all platforms. Not only that, but Microsoft have now fully open-sourced the next version of .Net and upon its full release within the next few months, it will be able to target multiple platforms including Windows, Mac and Linux.

C# all the things! Yay!

#5214694 Concept for an input library - thoughts?

Posted by axefrog on 05 March 2015 - 04:13 AM

Still, I wouldn't use a parser, but that's just me.

To be honest, I understand if it's out of fear of missing errors at compile time, but if it's performance-related, we're talking an algorithm that's basically going to be O(N), and given that the parsing will in almost all cases be less than 100 characters, and in many cases less than 10, the performance aspect is pretty much completely irrelevant. Not sure if you were concerned about that though. The win in terms of code readability, I think, is greater than the loss of compile-time input sequence type-checking. Just my opinion though.

#5214654 When and how do I start graphics? (C++)

Posted by axefrog on 04 March 2015 - 11:34 PM

Check out Casey Muratori's Handmade Hero course on Youtube. It's like having an experienced, old-school game engine developer mentoring you from the very basics. http://handmadehero.org

#5214646 Concept for an input library - thoughts?

Posted by axefrog on 04 March 2015 - 10:51 PM

I posted the link twice in order to reduce how much I have to repeat myself.  It should be enough now to simply point out that you still have the exact same problem and then let you read the post already-written.

You seem to be irritated by the (I believe false) perception that I haven't understood the point you're trying to make. The last sentence of what I wrote was the most pertinent. A combination of keys still maps to an intent, irrespective of whether that intent becomes invalid before it has a chance to be processed. The point is that your game should process intents, not keys, at the point where the intent is to be translated to a game state change. The conditions under which validation is asserted are, as you clearly keep pointing out, unique to a given game engine, but the original intent itself doesn't change. It still up to you to validate the intent, and if you're applying a log processing concept as per your other examples, then what is logged is the chronological set of intents, not the set of keys. The area of code dealing with the outcome of the intent should not be dealing with the keys related to that intent. If it is, your code is too tightly coupled.

In your example, you gave the example of remapping 'K' to 'A' and that needing to be immediately reflected, even if it happens right in the middle of a subsecond succession of bot-initiated keypresses. In my system, it is immediately reflected, because you feed the raw input event in at the top end, and it flows out the bottom as an intent, and that intent *was* perfectly valid at the precise moment that the input sequence produced that intent. If you're asserting that perhaps the key will be remapped mid-sequence, then that's splitting hairs. The process leading to the remapping would cause the key-sequence state machine to be reset anyway.

Second, you talk about timing, which is again a valid concern, but it still doesn't invalidate my solution! Irrespective of timing, input sequences and combinations still translate to an intent, otherwise the player wouldn't have pressed that combination of keys to begin with. If it turns out that they were 100ms too late, then your processing of the intent at the point where the intent is to be processed is where you would validate that intent. Even if you completely took away the obvious feature of being able to disable and re-enable an input sequencer (to avoid redundant processing of inputs), your validation on the end of your intent queue should still be correctly validating the next intent in the queue in the context of the game state as it is during that exact slice of time.

Perhaps you're pointing out a subtlety that I have missed, but consider this. The library is intended to be inserted into your main game loop, and nothing happens in your game without your game going through that game loop in sequential cycles. I know you've been around the block here, so forgive any blindness surrounding this issue on my part, but basic input processing doesn't strike me as something so resource intensive that it can't be included as part of your primary game loop. Therefore, even at the very start of your game loop, the game will be in a precise state, which is still reflected when the intent is emitted by an input sequencer, as it will be part of the same cycle, before the input library call completes. What you do at that point is up to you. If you are dealing with a parallel system, then again, it is up to you to validate that intent in the context of your game's state at the precise moment that the intent is processed, even if you relegated input processing to a secondary thread. However my point is this:

Device inputs map to intents. That's why we have input, because the player is trying to effect a certain outcome using their knowledge of the input device's (current) mapping to your game's systems. The point of the library is to translate intents from input signals to a language that your game understands. If an input sequence is invalidated midway through reaching a "completion" state, no problem, it's reset. If the intent that is added to the queue turns out to be invalid at the point it is to be processed due to 100ms of latency, again, no problem - you validate that intent before you process it. The fact that it wasn't valid at the precise moment it was to be applied doesn't change the fact that the player intended a given effect as a result of that input sequence. It's up to you, the game designer, to validate the intent before it is applied.

If you still disagree with me, the present me with a use case you think I can't handle, and I'll do my best to explain why I don't think it's a problem, and if I can't, then I will happily yield the argument to you.

#5214628 Concept for an input library - thoughts?

Posted by axefrog on 04 March 2015 - 09:26 PM

Spiro, your points are valid, but I believe you're quite wrong about this not being something that can be solved for most use cases. A well-designed game, as I understand it, is generally implemented as a complex hierarchical state machine, and the state of the machine is affected by signals it receives. I'm not sure how familiar you are with reactive programming, but input is just one stage of the combinatorial process.

Now, you are quite right that the input received is not universally applicable in the simplistic way that most new game designers are envisioning. Physics gets in the way (such as with your example whereby the space bar means jump, but not if they're already in the air). I think the reason you're having a conceptual problem with this is that you're not decoupling these concerns well enough.

With my library, the input sequencer is itself a hierarchical state machine, with each input sequence itself being a simple state machine. You still need to treat a sequencer as a child state machine in the larger state machine of your game! Each individual sequencer that you instantiate would be related to its own domain of concern, with its own group of mapped input sequences, and can itself be set to an "off" state, so that it doesn't trigger sequence-matched events when it's not relevant to do so.

Conceptually, think of it like this. Raw input maps to unified input, which is directed into my [proposed] library. You then use my library to build groups (my sequencer class) of domain-specific intents, where a domain is something like "main menu input", "inventory screen input", etc. and the intent is something like "Player Jumped" or "Menu Item Selected". The library maps the unified source input events to whatever intent group is active at the time. Those groups then fire events when any of their mapped input sequences are matched, and you then project that resultant event to a game-specific intent, which you can then filter using your own preferred model, whether directly, or via additional events, streams, queues or whatever.

In a nutshell, if you're having problems with universality of input because you're thinking that state matters, then your concerns don't have enough separation. Validating intent is not a concern of the input library.

#5214459 Concept for an input library - thoughts?

Posted by axefrog on 04 March 2015 - 06:04 AM

I'm thinking of building a small input library which would streamline the way input events are managed and make it a lot easier to observe complex input event combinations. The library would be designed to be plugged into whatever input source is desired, i.e. if you're using GLFW, or RawInput on Windows, or whatever, you would just point any events fired at this library and it would take care of the rest.

Conceptually, usage of the library would look like this:
// fires on ctrl+A, followed by ctrl+B, then ctrl+C, with a maximum of 1000ms between keypresses
auto observer = input::observe("ctrl+a,ctrl+b,ctrl+c", 0, 1000);

// fires when the mouse is moved
auto observer = input::observe("mouse:move");

// fires when the left mouse button is clicked
auto observer = input::observe("mouse:lclick");

// fires when the right mouse button is clicked while shift is down, followed by the space bar being pressed
auto observer = input::observe("shift+mouse:rclick,space");

// fires when the A key is pressed followed by a specific delay of between 500-2000ms, followed by B, then C
auto observer = input::observe("a,delay(500,2000),b,c");

observer.then([&](state) {
    // respond to input state here (the state object can be queried for any arbitrary keyboard/mouse/etc. state)

I haven't actually started writing any code yet, as I wanted to (a) see if anyone else has already written (and open-sourced) something similar, and (b) get some feedback on the idea. I'd be happy to open source this if others feel it might be useful to them.

Some extra thoughts:
  • The library could easily adapt to different platforms, e.g., you could add gamepad events and so forth
  • The library could be implemented as a template class allowing you to define your own event object that is passed when an event is triggered, and internally the library would provide an opportunity for the host application to add the input state object to the templated event argument object before it is passed to an observer, meaning that your event argument object could contain information such as the window handle where the event was triggered, and anything else (your game context object, game time class, whatever).
  • Registering an input observer could provide the option to ignore input of a given type, e.g. to handle situations where a key sequence is being observed irrespective of mouse state.
  • Gestures could hypothetically be supported as a future development...

#5214390 Question for UE4 and Unity 4/5 experts, regarding capabilities

Posted by axefrog on 04 March 2015 - 12:43 AM

Perhaps a more useful question back to you: Do you have the skills or resources to get it done?

I have the programming skills and experience (though not game-industry-specific), I also have the baseline math skills. Resources less so, though I'm expecting a change there in the next year or so, which may add additional capabilities. Fast/cheap/good, pick any two - I choose the latter two - this is a project I'm happy to spend years on, including developing core skills, and I've been doing that already. It's important to know my options though, hence the thread topic. Initially I only intend to build a proof of concept, and using that I may recruit others, or not. I'll take it as it comes. As I said, speed is not important, but if I'm going to spend a very long time on this, I want to be as educated as possible at the beginning, so I don't waste 18 months only to stop in frustration due to hitting the limitations of the path I chose.

#5212996 How do I know if I'm an intermediateprogramming level?

Posted by axefrog on 25 February 2015 - 07:16 PM

My $0.02:

A junior programmer has learned the core syntactical constructs of (usually) one language, and has performed enough exercises to be able to use their knowledge to write simple solutions to simple problems. To do anything moderately complex, they'll generally still need a lot of guidance, though, with sufficient help from a senior developer and constant review of their code, they can still be a useful member of a larger team. A mentor can make a lot of difference in helping a junior programmer reach competency (intermediate level?) sooner rather than later.

An intermediate programmer knows at least one language pretty well, has generally used it consistently for at least a few years, and may have dabbled in at least one or two other languages along the way. They've probably gotten used to using one or more libraries and frameworks too. As Sean was saying, they can use what they already know to do a reasonable job of solving problems that they are presented with, and even though the result may not be the most efficient, or most optimal, way of doing a thing, they can generally get it done without supervision. Intermediate programmers generally don't have enough experience to architect elegant solutions to complex problems. The term "architecture astronaut" is common at this level.

A senior developer usually knows more than one language pretty well, is very good at debugging, and more than that, is very good at writing code defensively, or in other words, knows how to write code and foresee potential errors and issues of efficiency that are likely to arise, this avoiding many bugs altogether. At this level, such a developer probably understands at least their core language in great depth and has a good working knowledge of several others. They can probably architect elegant solutions to relatively complex problems, though the actual level of competency in this regard can be vary, because the term "senior" can be somewhat amorphous. If I hire a senior developer, I expect to be able to provide them with a task and not have to worry about whether their code is going to negatively impact the codebase as a whole. I expect them to have a pretty good idea of what they don't know, and be proactive enough to fill in their own knowledge gaps as needed.

The upper end of senior developer crosses into areas like "lead developer" and "software architect", which I generally don't see from developers with less than at least 10-15 years of real-world development experience. One thing I find interesting is that I come across developers who have "10 years of experience", but almost all of it is at the same job, doing the same thing. Those developers, I would say, probably stagnated after 2-3 years and, having not been exposed to new ideas, new challenges and alternate approaches to problems, have not risen above the level of junior-intermediate developer, which can be quite a shock to them when they finally end up back on the job market, claim that they are a senior developer and then fail miserably in interviews when they are asked standard senior-level questions and have no idea how to answer.


If you want to go from junior to intermediate and beyond, always assume that your code is probably crap and can be improved. Retain an insatiable need to get better at what you do, read articles and books written by those in your field that you look up to, never be afraid to ask a lot of questions and risk looking stupid. Above all, be genuinely passionate about writing code, solving problems, building things and doing the best job you can do.

#5212331 Modern 8-bit game

Posted by axefrog on 22 February 2015 - 03:34 PM

Four-colour CGA graphics!