rnlf_in_space

Member
  • Content count

    227
  • Joined

  • Last visited

Everything posted by rnlf_in_space

  1. Leaving a company at a critical moment

    During the interview for the job I have now, I told the interviewer that I felt it was my obligation to help my previous (then current) company finish an important project and asked them to let me start 2 months later. I expected that to be a problem for them, but quite the contrary: After the interview, they told me they had talked about that and found it meant I was a loyal person and that they felt assured that if I ever left the new company, I'd give them enough time to find a replacement, too. Have you tried talking to the new company about the issue? Maybe they are more open to it than you think.
  2. How about using something preexisting? I really like Visager's music and it's available for free: http://freemusicarchive.org/music/Visager/
  3. C++ Convert functions to linux (gcc)

    I think you may want to use CLOCK_MONOTONIC_RAW instead of CLOCK_MONOTONIC. It doesn't make a huge difference, and mostlikely never causes any notiveable problems, but CLOCK_MONOTONIC may run slower or faster than "real" time, when the clock gets adjusted. Basically, a correctly implemented tool to set system time on a UNIX system will not just set the new time, but rather slow down or speed up the system clock to gradually go to the new time. This is so that there are no jumps in the system time, which will throw off a bunch of things on a UNIX system. CLOCK_MONOTONIC is subject to these adjustments, so you might experience a time where your game does not actually measure one second of realtime as one second, but rather as 1.1s or something like that. CLOCK_MONOTONIC_RAW is never sped up or slowed down.
  4. C++ Convert functions to linux (gcc)

    There's clock_gettime in Linux. It gives you the time with nano-second resolution (but lower precision, usually), but clock_getres can be used to find the actual precision. You may want to use the clock named CLOCK_MONOTONIC_RAW to get the actual real time that has passed.
  5. C++ Bit manipulation returning wrong data

    I'm not sure why you even want to go through all the trouble of packing your data like this. Just return a struct { int mouse_x; int mouse_y; } and you're done.
  6. Video codecs: compressing delta values

    I don't know much about the topic, but you don't actually need one extra bit for the difference if you wrap the difference around at the 1-byte border: The difference from 255 to 0 is -255, but can be expressed as +1: (255 + 1) % 256 = 0. The difference from 0 to 255 is +255 and can be expressed as that: (0+255) % 256 = 255. PNG does that for some row filter methods if i'm not mistaken.
  7. std::string_view

    Yeah, this can all lead to an explosion of overloads very quickly. I think passing an std::string by value and then moving from that string to initialize your members has the best performance/effort ratio. This talk by Nicolai Josuttis illustrates the problem very nicely, even if for slightly more complex cases: In your case I'd probably just go with Str(std::string str) : m_str(std::move(str)) {}, that way you create one copy of your string at the call site and then just use the (comparatively) cheap move constructor to initialize your member. std::string only has an explicit constructor that takes a string_view though, so if you'll either have to create the string object at the call site, too, or overload with something like Std(std::string_view v) : Str(std::string(v)) {}. I'd prefer the first option (making the copy explicit at the call site) because it doesn't hide the extra allocations and memcpy.
  8. std::string_view

    string_views never own. The ambiguity comes form the fact that you are creating a temporary object out of your string-literal. The compiler cannot figure out which of the two possibilities you want, either a string_view which will then be used to construct a new std::string in your constructor, or create a temporary string object and then move-construct your member from that. I don't see a good reason to use string_view here, you'll have to make a copy sooner or later anyway, why not create it at the call site and forgot about all the difficulties you are facing now?
  9. What is the best OS and IDE for game dev?

    Unreal engine works fine on Linux. Epic even provides the build scripts and everything (IIRC, might have gotten them from a third party? But I don't think so).
  10. As jpetrie said, you cannot call the default constructor, because there is none auto-generated. Once you define a default constructor, you can.
  11. Blank Programmer.

    It certainly doesn't hurt to diversify your skills. If you really want to, take a step away from full featured engines to simpler frameworks, like LÖVE, prototype a bit with it and learn a new language in the process. You can still use Unity in the end for all your "real" work, but I think learning more languages, frameworks and programming paradigms will help you improve your work in Unity, too as it gives you a bigger toolbox of ways to think about tackling certain problems. It will also help your knowledge not to become obsolete should Unity ever fall out of favor of the dev community. In my opinion, if you're a "real" programmer isn't determined by the tools you use but by the mindset you have. Always be curious, try new technologies and use the knowledge you gain from that in your daily work. I guess only ever applying knowledge you already have to new projects could become very boring after a while, too. Always push the limits of your knowledge, even if it's just to avoid being bored by your work.
  12. Atari purchase question.

    Which Atari? For a 2600 this game seems a lot too complex, graphics wise. The 2600 has very limited drawing capabilities and is really difficult to program for (you need to program 6502 assembly and get the timing exactly right, to the precision of a single clock cycle of the CPU to get a the result you want). If you have to ask here instead of being able to find this information in Google, I'm afraid you may not be ready for this. Maybe start with an easier target? Like C64 or DOS?
  13. With C++17 you'll also be able to use std::variant, which is basically a type-safe union type. Not sure if C++17 is an option for you, but I thought I'd mention it. That doesn't allow type punning though.
  14. Looking for an good pixel art editor

    FYI, you can get Aseprite for free, if you're okay with compiling it yourself. Only the precompiled version costs money at all.
  15. Copyright if the Singer sit in jail (long time)

    Someone does own the rights. You have to pay them if you want to use their property. What's so difficult about that to understand?
  16. Honest question about C++ vs C#

    Just wanted to note that I really love the race car driver analogy. I'll steal it from you.
  17. A compiler is not required to provide types of all sizes. The standard says nothing about the availability of certain types. It just defines relationships between built-in types and explicitly makes all the fixed-width integer types optional for exactly that reason.
  18.   That is not entirely true. It's only true when char is 8 bit. There are architectures (that I had the questionable honor of working with) where char was 32 bit and therefore sizeof(uint32_t) == 1. But it's true on all architectures you may encounter in gamedev today. It's just not universally true.
  19. RT @IL0VEthe80s: I had He-Man & my sister had Sindy. Sometimes they'd go on a date. He usually ended up trying to chop her head off ? https…
  20. Each iterator comparison

    Your are comparing the iterators while you really want to compare the value of the items in the two lists you are comparing. I would think changing your problematic line to if(*objlist_iter == *iter) should solve the problem. The next problem is that you are trying to erase an object from a list with an iterator of a different list: CObjMgr::GetInstance()->Get_ObjListForKey(tcDelKey)->erase(iter); iter is an iterator of m_ToolObjList. You should CObjMgr::GetInstance()->Get_ObjListForKey(tcDelKey)erase(objlist_iter);
  21. Episode 8 of my Little Big Adventure playthrough on a 486 machine: https://t.co/lTx3yv0lrp #retrogaming #RetroComputing
  22. What are sprites ?

    That really depends on the hardware you are talking about. On old systems, like NES or Sega Genesis, sprites were a hardware thing. The video processor would construct the image by tracing the scanlines of the screen. It had a list in memory that contained the information about all the sprites on the screen (a relatively low number, usually, like 64 on the NES). Then it would scan this list on each scanline to find out which of the sprites are touching this scanline, then load these into some special hardware register and produce the color while moving the cathode ray across the scanline. Sprites were very limited in both dimension, color and total number (per screen AND per scanline: the NES for example only allowed 8 sprites per line, the 9th would be invisible). Usually sprites had one or two possible sizes, could not be rotated or scaled (sometimes they could be flipped vertically or horizontally though, for example on the NES). Later, framebuffers were "invented" or rather became usable for mainstream games. Here, the whole image is constructed in memory before it is being sent to the monitor. The basic principle is the same: The graphics processor would read the memory for the current pixel location on screen and output the signal needed to produce the right color. With this, it became the job of the programmer to define what a sprite really is and what you could do with it. In the early days, these sprites were just "blitted" onto the background by copying memory around. That meant, they usually didn't support scaling or rotation either. This is mostly due to all the calculations being done on the CPU (the mixing, blending, scaling, or whatever effects you allowed on your sprites). As CPUs became faster, people started adding more features, like rotation, scaling, transparency and all that nice stuff. Then, GPUs happened. These are good at drawing textures triangles, and as it turns out, you can represent almost everything you did with the old sprite systems by just creating two textured triangles. So instead of writing the sprite functions to do all the memory operations themselves, people wrote them such that the GPU did the job for them. The basic principle is still the same though: In the end, you fill a big memory area with the byte representations of the pixels. On today's games we see mostly the last two options: Either you use software blitting routines or you let the GPU fill the memory for you. In GL 3.3, you just create a texture, upload your sprite data to it, then you create a vertex buffer containing the corners of your sprite and the UV coordinates (which tell your shader how to attach the texture to the triangles), a vertex array where you define the layout of your vertex buffer (i.e. where in the data can it find the world location of the sprites' corners and where to find the UV coordinates), then you create a fragment and vertex shader (which are probably exactly what you'd find when searching for some basic textured shader tutorials). Once you've uploaded all this data to GL, you can draw. It's a bit much to explain all that here, but every beginner level GL 3.3 core tutorial should cover these topics. I hope this helps!
  23. Little Big Adventure on a real 80486! Let's Play Episode 4: https://t.co/UCzjbfi6Fs #retrogaming #retrocomputing