Jump to content
  • Advertisement

gaxio

Member
  • Content count

    14
  • Joined

  • Last visited

Community Reputation

10 Neutral

About gaxio

  • Rank
    Member

Personal Information

  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I like global events for this type of thing, especially in Unity. I often have a UI scene I load additively on top of other scenes and the buttons are all hooked up to global events. Things in other scenes are listeners in these events and it all works well without objects in the UI scene having to know about objects in the game scene or vice versa. The first thing I do is define structs (in C# this is nice since they're value types, they don't make garbage) to define the events, I'll have structs like EVUIStartButtonPressed or EVGamePlayerDied. These structs not only define the presence of a type of event, but also all of the information about the event. So EVGamePlayerDied will have at the minimum a reference to the player so any code listening to the event can tell which player died, or query the player object for information or something. Then I have a template class that just looks something like this. Again, this is C# and Unity, but it's a generic concept that can extend to any language or framework. public static class Event<T> where T : struct { private static event Action<T> ev; public static void Add(Action<T> action) { ev += action; } public static void Remove(Action<T> action) { ev -= action; } public static void Invoke(T evData) { ev?.Invoke(evData); } } This is a templated static class, which means Event for each event struct type is a different type, and that any of those types can be referred to by any object in any scene. This allows your UI code to call Event<EVUIGameStart>.Invoke(x) and your GameManger to call Event<EVUIGameStart>.Add(GameStart). They don't have to know about each other, they just have to know about this common, generic event. The only downside to this is that you need tiny scripts everywhere that just kind of hook things up to events. It's not much of a problem, but it's annoying.
  2. gaxio

    Simple trig problem driving me crazy

    I'm glad it worked out for you. Trig is one of those things that I have to draw out or I don't understand and if your head is not in that space often then it's easy to get things backwards or just forget how it works, causing issues like this that just leave you scratching your head. Thankfully, this is where abstractions come in. You're one step away from a transform hierarchy now, a general form of having "game object" with local positions, rotations and scales and a parent game object that has all of the same including a partent game object. All the way up to a root node. This allows you to just take entire parts of your scene and move them around naturally.
  3. gaxio

    Simple trig problem driving me crazy

    I haven't dug into this problem but I think you should look into using Transforms. This is what Transforms do, transform a local coordinate space into another space like the global, camera or viewport space. You're going to be doing trig everywhere if you don't use transforms and it just seems like there's a super-simple solution already done for you in the library you're already using and you're not using it.
  4. 78 parts? Wow, no one can accuse you of half-assing this. I'm definitely bookmarking this should I ever get interested in Pico-8.
  5. gaxio

    Game collectible highlighting

    Yes, this is done in a shader. This can be one in any number of ways, but I've done something similar by testing the fragment's world position against a value and calculating a color to mix in the with sampled texture. All you need to do at that point is to sweep the position you're comparing to over the object over a number of frames. To know how exactly it's done in any particular game or how it could be done in your game, more information would need to be known.
  6. gaxio

    Thread safe architecture

    As far as I understand it, Twisted is going to make things a whole lot more complicated. I have never used Twisted, but I have used a similar library in Ruby called EventMachine and you have a lot of autonomous pieces all over the place. While this seems good at first, for something highly synchronous like a game server I think you'll find that it's counterproductive. What I would do for a game server is have a single thread that performs all the logic at a constant tick rate. Each socket reads in messages and adds them to a queue for that single thread to process. This can be as simple as a select (the system call, not the case/switch/select language construct) in another thread, or something like goroutines in go, which would be similar to how Node does things asynchonously. The point here is that all your async stuff does is gather messages and add them to a queue for the main thread, which wakes up at regular intervals to process them, update the game state and then hand off game state updates to be send to the client asynchonously. Race conditions won't happen here because you have a single point of synchonization: accessing the main thread's queue. It is an extremely simple architecture that will scale well for smaller scale games (if that makes any sense). If and when a simple architecture like this doesn't scale to meet the needs of your game, then you should start looking at more complex architectures.
  7. gaxio

    Pixel Art Resolution

    Thanks for the fleshing that out. I also forgot to mention that step 1 is optional if you have enough control over the renderer. If you can control how sprites are rendered then you can render directly to an integer scaled render target with unfiltered scaled sprites locked to fat pixel boundaries. At that point all that's left to do is to scale to screen resolution, or your letterboxed/pillarboxed final size. Also, you can ignore snapping sprites to fat pixel boundaries. Movement becomes a lot more smooth, but it's not "true" pixel art since some sprites won't be on pixel boundaries. However, most users don't notice that they just say the game looks smoother. I did this first on a breakout-style game by accident and the ball just looked so smooth that it was hard to ignore it. It's usually what I end up doing now since it looks so much smoother.
  8. gaxio

    Allegro Lives! Try it today!

    Allegro 4? What's this new fancy-pants stuff you're talking about? I think the last version of Allegro I used was Allegro 3.x in like... 1998.
  9. gaxio

    Pixel Art Resolution

    The first sentence is correct, but the rest is incorrect. Yes, if you try to scale from a low resolution directly up to a high resolution with texture filtering on it will be a blurry mess, however, see my other post in this thread for a method many games used to scale sharply and accurately to arbitrary sizes. It does not always look like ass if you use texture filtering, it is the key to get pixel art to scale correctly if you can't scale by an integer amount. Pixel art will also never scale correctly at non-integer sizes with filtering turned off. You'll get situations where most columns of an image will scale to 2x2 pixels or something, but then at regular intervals throughout the image rows and columns will scale to 3x3. This is bad, this looks terrible and any scrolling screen or moving character will warp and distort.
  10. gaxio

    Allegro Lives! Try it today!

    Wow, I haven't used Allegro since the 90's or so. That's where I got my start in gamedev, DJGPP (which is also still around, yes, you can use C++17 on MSDOS) with Allegro. I can just remember the utter frustration though. I had no resources, no access to the internet, a 486 66MHz with a painfully, painfully slow 120meg hard drive and a quick reference guide for C that I was trying to use to learn the language. Every day at school I'd go on the Allegro forums (or.. where was that? This was before allegro.cc, I remember that site launching) and print off stuff to read at home. I didn't make much progress, I think I got a basic tilemap going and Bowie from Shining Force walking around. Then I got Linux and a bunch of books about that and there was much more stuff to learn there, and eventually I was using SDL on Linux. I don't think I've ever looked at Allegro seriously since then, maybe I'll give it a go for a laugh. Or hell, boot up DJGPP, Rhide and Allegro on MSDOS. At least this time I'll know what I'm doing.
  11. gaxio

    Pixel Art Resolution

    Your screen resolution does not have to be divisible by your canvas resolution. If you want perfectly sharp pixels then it helps, but there's a trick to get a canvas of nearly any resolution to scale well up to your screen resolution. Render the game to a render target that's the size of your virtual canvas Scale that canvas up as close as you can to the screen resolution, but make sure you scale at an integer multiple of your canvas size and without any filtering. This will results in pixels being turned into 2x2, 3x3, 4x4, etc clusters of pixels. I call these "fat pixels." Scale this integer scaled canvas to your final screen resolution with bilinear filtering. There will be small transitions between the fat pixels but most people never notice this. In fact, most modern pixel art games you've played probably use this technique and you didn't even notice it. For example, look at the two images I attached. The first is a screenshot of Shovel Knight, and the pixels look to be quite sharp and nice. It's not blurry, the pixels are all uniform size. But then look at the second attachment, I've cropped out his face and blown it up with no filtering. See the transitions between the pixels? They're using this method and most people who play the game don't even notice. So no, you can make your canvas size be anything you want.
  12. gaxio

    Assembly language?

    If you would have continued reading just one sentence down the road, it's clear I was talking about assembly in game development, not assembly in general. Of course there are resources about assembly programming.
  13. I hate to be "that guy," but why not? A lot of people want to do everything themselves and try to set off doing just that, but it's really hard to do game development that way while learning. Games are hard to make, why make it harder on yourself? Further, a lot of people who set out on that path don't even know how other games and engines are architected, so they don't even know how one could make a game, let alone how they want to make theirs. This all spells frustration and failure. I suggest you get Unity and, even if you don't stay there for more than a few months or a year, learn how games are made in Unity. This will at least show how things can be done from above and will help you prepare to make them yourself from below. As for this book you're using, I'd just get rid of it. It's hopelessly out of date, Visual C++ 6 is ancient and wasn't even very good when it was new. Though I'm saying this with no replacement book in mind, I just think that unless you know how to work through the many errors you'll be getting that it's not going to be worth continuing. Or, if you're really, really intent on continuing with this book, get a Windows XP machine. Ask around, check Craigslist, you can get decent XP machines for practically free, a video card on ebay will cost you a few dollars and you'll at least be working in the native environment the book expects you to be working.
  14. gaxio

    Assembly language?

    There won't be that much information about this and there certainly won't be many introductory tutorials. You've strayed far, far into DIY territory and something that's not even practical or even in wide use in game development. You will find generic information about assembly language programming, of course, but you won't really find anything about game development. That said, assembly is a lot of fun. One of my hobbies is 16-bit x86 assembly on DOS, and this is old enough that there is actually information about this available in the form of text files and books (many of which can be had on Ebay for $5 with free shipping). It's also interesting and rewarding having an entire machine to yourself and controlling the video hardware manually. This is as far from modern as you can get, but if you're interested in this I can dig up some info for you. But in the end this is a real hardcore path that I only recommend if you're extremely persistent. Games are complicated as they are and programming one in assembly when you're just learning assembly is a real tall order. You won't find much or any help, you're going to have to be really self-reliant and know how to solve problems yourself.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!