Jump to content
  • Advertisement

mr_tawan

Member
  • Content count

    53
  • Joined

  • Last visited

  • Days Won

    1

mr_tawan last won the day on April 10

mr_tawan had the most liked content!

Community Reputation

159 Neutral

About mr_tawan

  • Rank
    Member

Personal Information

  • Role
    Programmer
  • Interests
    Art
    Audio
    Programming

Recent Profile Visitors

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

  1. I think, if you're using Windows API and you sets the API awareness right, then you wouldn't have to worry about the scaling. https://msdn.microsoft.com/en-us/library/windows/desktop/mt843498(v=vs.85).aspx
  2. Are you working on some kind of custom UI Widget toolkit that runs on Windows?
  3. The best way (so far) to prevent cheats and priracy would be ... streaming. Input is taken and sent directly to the server with almost none processing. Server produces an output image and sent it back the the client. The client is just an absolute dumb client that do almost nothing. The downside is it relies heavily on the server and the infrastructure around it, including the connection between the client and the server. And I don't think this can totally elminate cheats. Player will find a way. This is not suitable for indy developer I think, too expensive. Commercially I've heard only a handful of service that do this way, including RE7 on Switch which is just annouced recently.
  4. I joined a number of game developer communities since maybe '99 (GD.net since 2004), and I started coding around 2001, when I was in colleage. Since then I do a number of projects, but none of them really finnished. In fact most of them never leave a proof of concepts stage. I joined a game company in '05 for a year. The only game that I take parts of development and get published is Barnyard Blast (for Nintendo DS), which I only work on it in the demo stage ... I don't think my name is in it credit list though ... Since then I have coded a number of custom game engine, but I've never managed to finish any of them. I trashed a few dozen of them engine since then. Recently I"ve just picked up Unity2D I joined a local community as a composer, as I couldn't code at that time. The first project I joined with the people there never leave design stage. ... I've foolishly think "well I can code, I can compose, I can do game design, ... what if I do the arts myself too?" even after a number of projects that never leave proof of concept stage. I started learning how to draw 2D arts a few years ago, and still terrible at it. Sometime I feels like I am the protagonist of the manga 'Kakanai Mangaka', only as a game developer rather than the mangaka. .... I think, what I'm lacking are 'commitment' and 'focus'....
  5. You are totally right. I've seen no one can master a skill without hands on experience before (that would be a genius)
  6. I'll say, that goes for many people, myself included. Don't worry :). Anyway, for Clean Code and the Clean Coder, it doesn't really about teaching you a superhuman programming skills. It's more about simple things that you might overlook. Clean Code is like ... ie. how many line should a function be, what comment you should and should not put in the code, etc. And The clean Coder is more on the professionalism, things like estimate, and stuffs It's pretty much a generalized guideline. The C# in a nutshell is... a reference book. It's similar to dictionary. I don't think dictionary is supposed to be read cover to cover (that would drive me nuts). Personally I just skim through the book, and sometime learn something new. The better use of this one is like when you see some code that you don't understand, you can reach out to the book and seek for some more explanation. Of course this is only achievable when your basic knowledge is strong enough.
  7. My suggestion might be a bit odd, but I'd suggested you to read some programing practice book. I find Uncle Bob's book (Robert C. Martin) quite interesting eg. Clean Code, The Clean Coder, Clean Architecture, etc. Also, this is even weirder, you might want to try skim through books like C# 7.0 in a nutshell to see how much of C# you understand. You will find something interesting there. What else... hmm... what about a good Winform/WPF book just in case you might need to do some tooling one day? Who knows when Unity's built-in tool and extensions might not suffice (I assumed that you're using Unity, but may be I'm wrong).
  8. The scaling algorithm like nearest neighborhood uses multiple texel to calculate the output texel value. So imagine that if the target texel is around the edge of the sprite, the texel value from the neighboring sprites might be sampled to use in the scaling process. This could results in artifacts if the texel values are too much distict. Supposed I have a sprite sheet texture that looks something like this. And the sprite I'm using is the black one. If I draw the sprite with 120% scaling (for example), I'd expect a larger black square on screen. Instead I'd have this. The red lines around the black square is the artifact I'm talking about. As @Scouting Ninja mentioned, there's no way to prevent the scaling error. The sprite has to be drawn specifically to minimize the artifacts that can happened in the scaling process. One way is to add the margin around the sprite. Anyway, tools like texture packer should helps you minimize the problems. Currently I have sprites in its own separate files and let the texture packer do the margin and stuffs for me. It's seems to be working well so far.
  9. AFAIK, there are 2 ways to handle this. Letterbox - render the output to the largest area possible inside the game window while retaining the aspect ratio. The rest might be painted black or have some kind of static images to fill the void at the edge of the screen. Safe Frame - render the output to the smallest area possible that cover the whole window while maintaining the aspect ratio. This implies that the main content is within the safe area at the center of the screen, as contents nears the edge would be eliminated in the case that the aspect ratio doesn't match. This is very similar to what TV people does. There are pros and cons with those two methods. Letterbox is much easier, but it doesn't look as nice (some players will complains about this all day long). Safe Frame means different players would have different experiences (depends on their screen size). It is also more difficult to design around it. Imagine a game designed around 16:9 ratio target resolution running on 21:9 ultrawide screen or 3:4 vertically placed screen, a lot of display area would be invisible in these cases. One more note, UI could be drawn on top of the game content after the scaling (rather than before scaling). This makes the UI looks crisp even if there are some scaling, as UI is not scaled. Of course this have to be taken into consideration when design the UI layout as well. Floating UI tends to work well in this case.
  10. You've mentioned that the pointer is valid. What's about the member variable of that object? Are all of them valid or not?
  11. mr_tawan

    C vs. C++ vs. C# (Beginner)

    Indeed, they are quite similar. MonoGame does something more than SDL or SFML do, like the content pipeline, content manager and game lifetime. All of these extra can be easily implemented.
  12. I'm not a big fan of scaling every sprite on the screen, as it can lead to artifacts if you're not careful enough. Every sprite will need 1- pixel guard around it. Otherwise, when scaling is done, the surrounding texels will be used in the scaling algorithm and results in artifacts. One thing you can do is to use 2 different resolutions, one for display, and one for drawing/game logic. I think this is something called virtual resolution or target resolution. Basically, the display resolution will be varies based on different settings. Screen sizes, windows sizes, etc. On the other hand, the target resolution will be fixed. All the drawing and the game logic will be based on the target resolution. This can be done by using render target. Basically, a render target texture will be created with the same size as the target resolution. All sprite drawing will be done to the render target. And once all drawing is done, this render target will be drawn to the screen. The scaling will be done once at the last step, and since we fill up the screen, artifacts will be off-screen. The disadvantage of this method is it requires hardware support for render target. I think almost every hardware in the market now supports render target though.
  13. mr_tawan

    C vs. C++ vs. C# (Beginner)

    Looks like I misinterpreted your question. My bad!!. Since you're going up a step from the complete beginner, and since you're quite familiar with C#, personally I'd continue with C# if I were in your shoes. Many of the concepts in C# can be applied to C++. You will be able to switch to C++ when you want to with a few adjustments (like using less `new` and use `delete` to free dynamically allocated objects). C# also has an advantage over C++ in the area of package management. Nuget is the de facto standard for .Net. C++ module is still being standardized, and while there're package managers for C++, they are tied to the platform rather than the language. The disadvantage of C# over C++ might be in the performance area (of course, it depends on so many factors, let's just don't go there), and the ecosystem. Many game-related libraries are in C and C++ (both works with C++), which does not directly compatible with C#/.Net without binding. Hope this helps.
  14. mr_tawan

    C vs. C++ vs. C# (Beginner)

    Personally, I think, C++ is easier to start than C. However since it covers more ground than C, it ends up spending more time learning C++ than C. I usually suggest people to get started with the procedural/structure in C++, which is basically C with a little bit extra to make it easier to code than pure C IMHO. C# is a kinda different beast than those two. Getting started in C# can be a little bit overwhelming at first. Anyway, I don't think it's a bad thing to start with C#. You can't go wrong with those three. Just pick one and stick with it until you master it. After you've master one, you'll find that you can learn other programming languages in no time. One thing that you might want to consider is the ecosystem around the languages AND around yourself. I mean, you might know some programmer who is really good on one of those languages. Ask him to be your coach -- ask him for advises and code reviews (you might have to pay a little bit for that though). Learning alone can take more afford than having someone to help you. Also, if you are interested in, for example, Unity 3D, learning C# in Unity3D can fire up your interests which in the end you help you get through the learning process better than say learning coding in console for example. One last thing is there is no right or wrong answer. Everyone takes different approaches when it comes to learning. Just stick with one for a while and see if it works for you, and switch if it doesn't. Just my 2 cents.
  15. Just to throw my 2 cents in. It depends on what you want to archive. If you wants to learn the actual game programing, then go with the engine might not sound too bad. The current day game engine provides lower-level of game programing than what it used to be in the past. Unity3D is probably your answer. If you want to learn how the game engine works, or creating your own (which you have already created your own), you might want to go with framework/library. MonoGame (C#), Cocos2D-X(C++), SFML(C++) LibGDX(Java) or LibSDL (C) allows you to create your own engine to run on multiple platform. It abstract the platform-specific code away so you don't have to deal with the low-level stuffs. However it's low level enough that you have controls on almost everything, including scene management and stuffs. From that list I think MonoGame is the easiest one in term of getting code runs on multiple platform, but your experience may vary. You can of course writing the code to the target platform directly, but that means you have to do the abstraction layer yourself if you want the same code ot run on multiple platform, which will be time-consuming.
  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!