Krohm

Members
  • Content count

    3160
  • Joined

  • Last visited

Community Reputation

5036 Excellent

About Krohm

  • Rank
    Contributor

Personal Information

  • Interests
    Business
    Programming
  1. Maybe not appropriate but when I hear about full stack I usually think 'web'. IDK if there's a full stack equivalent in gamedev but I'd suggest you to stay away from that terminology. In general people advertising as full stack are full stack web devs doing both the HTML and the back-end. A few of them are in electronics and they go from HW (usually PCB design) to (usually) server. I had to go from firmware to HTML front-end and I'm still very reluctant in describing me as a full stack developer. Anyway, in my experience the main problem is getting where you need to be. In six years, you should have stashed some to allow you that. Look around. Ah, btw. While I find being able to get the job done and adapt to other roles occasionally to be admirable this isn't a good idea for the reason Kylotan mentioned. Do you know who also finds it valuable? Companies who cannot afford to pay multiple wages. I'm absolutely not talking by experience. Be ready for a rough ride.
  2. Wow, that looks cool. I wish I had not an allergy on pixel art!
  3. As a start: do you want/need it to be native app? Yes Do you want it easy? Yes --> IDK, I'm pretty sure Cordova, Xamarin and Ionic are a thing. I'm not sure what's their state though. I'm up to the task --> native platform for each. Android studio & Java. For Apple IDK. I'm hardcore --> go truly native C++ and share your logic across platform. Farewell life. No Make it a web page with offline mode Angular does not currently support static deploy anymore Maybe with the right tool, electron? Sure thing: you want a language to help you. You want types. Types help your mind scale instead of recalling what gets passed where. Typescript melds into node.js very well. So start by elaborating. What do you want to do, how much do you want to invest, money, time everything; define the thing better than people clicks on device.
  4. Bullet ForkLift can't stand firm on the floor

    I get the idea you built it from multiple components with constraints. I remember an user from the forums here who worked on vehicle simulation stating they run the vehicles at 200hz. Have you tried bumping up the iterations? Does it change anything?
  5. Or go with pupping and have a single function to read, write and compute size. No repeating yourself but I feel like beating a dead horse at this point.
  6. Node Graph UI for Accidental Noise Library

    Wow! Everything is better with node graphs!
  7. I'm not even sure what's your problem there. Let's start from the basics: the only thing that truly exist is memory and bits. As long as you're going with 'basic' types such as floats the following will do: ubyte blobby[12]; memcpy(blobby, src, sizeof(blobby)); float *bruh = (float*)blobby; Hoping `blobby` to be properly aligned. First you have to ensure your `int` is the same as the serialized `int` and that's why you have `__int32` or `std::int64_t`. And of course you have endianess problems but let's assume you'll be loading on 'coherent' machines. When `struct` enters the picture `memcpy` goes out due to possibility of different compiler packing. There are various options for (de)serialization, I'd suggest pupping all the things. That or google protobuffers but in my experience they're not quite convenient for game purposes due to their everything can be optional nonsense.
  8. You have three obstacles here: Windows XP is greatly outdated; I have been bitten by it years ago. Some functions are not there, whole subsystems are missing. Solution: go Linux®. 512MiB of RAM are barely enough to run the IDE (the smart text editor you'll be writing your programs in). The engines you mention will most likely malfunction. You have a single core. In my experience modern systems take for granted at least a dual-core is available. Your measurements will most likely be screwed big way in a way or the other. If budget is a concern to you, I would suggest a Raspberry Pi3 which for 40 bucks is a far more reliable and stimulating programming environment (also comes with twice the RAM and can arguably run a modern web browser). Ah, btw, as much as doing tic-tac-toe on Unreal might sound cool, I'd suggest starting from the basics. As a side note: No. Absolutely not. What the server does is connect the players. You don't want any heavy-duty processing going on the server, you'll be paying $$$ for saving nothing to the client; client performance is free to use for you; server time isn't. 18 months ago I bought a smartphone for 70; it runs on battery and still has plenty of juice for everything I thrown at it.
  9. If I understand, your generic problem is: you have an object container with an object inner inside. You destroy container and poor inner goes with it. Too bad you need to keep referencing it so you're blasted and you need to reconstruct. All fine and dandy but... you have misunderstood your resource ownership . If inner is owned by container then when container goes it brings its owned resources with it and user systems are screwed. In the general sense of particle systems that sounds bogus but maybe you're more like "replicating" objects somehow so what you do? Review your container to use external resources allowed to exist by themselves. When newOwner takes control of them, pull em out of container or mark them 'non-owned'. When container goes belly-up it either destroys its owned resources or they get destroyed by some external function doing the check at higher level.
  10. As a side note, in case it helps you (on some future project I guess): bullet (the physics API) ticked at constant rate, but it still allowed for frame-specific updates. OFC it only interpolated those between two known states. So it's has both predictable behavior and hi-frame-rate-butter-smooth goodness; apparently nobody noticed it's a tick late. I tried something similar in an TD game I tried years ago I don't think you remember: the implication is that you have to correct for inconsistencies as an enemy spawned at 0.5 tick still has to be half-a-tick evolved and cannot be backwards interpolated at 0.3 ticks. Since the game wanted to be deterministic in nature I couldn't let players the chance to get different patterns due to hardware power. Ew! Hopefully you don't need this detail!
  11. Question about C++ , C# and Java

    I always found Qt nonsense to say the least - it carried on because it's slightly better than the alternatives but it's a behemoth in itself. If you're doing GUI apps C++ is most likely the worst language/ecosystem you can pick. When you talk GUI, the solution is very well established IMHO: Angular. Wait, what? When I first heard of Flash to be used for game GUI years ago I thought it was terribad idea. But then there has been CSS3, V8 performance improvements, browsers are the most powerful layout engines around they can do everything you want, with HTML5 you're pretty much done across all operating systems and sorta recent browsers. Qt can follow as much as they want but browsers can be compiled in the app nowadays. How does Atom work being CoffeeScript and Javascript and what I'm shooting at? Under no circumstance I will consider GUI part of my application Never, ever again. 3D we can talk but GUI stuff, I won't touch those things anymore with a ten foot pole. I'm doing "service" style apps right now so I have it easy: pop out an HTTP/websocket server and have the GUI in the browser. If I'll have to do a stand-alone web app I'll look into electron, let it put it bluntly: the GUI wars are over, browsers are the winners and your users expect it too. As far as I am concerned any GUI not running in a browser is dead or a dinosaur allowed to live in some specific ecosystem. Or, you could elaborate on your true, specific needs. Perhaps that would get us somewhere.
  12. Woah! I just had the need for some graphing goodness the other week and I forgot completely about dot. Perhaps I'll give it a go. Thank you for sharing!
  13. Please guide me?

    As a start consider a game is much more than code. In my experience simple games run great in browser. Everybody can play them, they're portable, need no install and nowadays you can get quite far with them I mean pure HTML/JS stuff. OFC you don't use HTML nor JS but some framework, and maybe Dart or Typescript. And there are plenty of frameworks. Plenty. So you want to go programmer route? C? Say no to C. You'll get mad very soon. I don't suggest C++ either. C# is kinda good. Or, you could just play a bit with Unreal, see what you can do, learn a bit about pipeline. Make a few levels learn a bit about gameplay. Or heck, you could just buy some games off steam or the humble bundle and see what you like. Sketch a plan.
  14. Multi-level Water

    Any chance you have enough perf/functionality to just expand each prism to a buffer and somehow ray-walk it? After playing the Talos Principle I had to surrender to the fact Parallax Occlusion Mapping (of sort) is now fully viable so maybe having some kind of "fog collection buffer" with dual layers might work. Plus, everyone and the dog is doing terrible screen-space reflections.
  15. There are indeed a variety of ways, I know them as 'tags' and in theory they work... except for some reason they really don't in this specific case. I use sourcetree so it's just a matter of pushing a button. Well the snip is a full SHA and I've had a collision already in the past (not on SHA) so I feel quite safe for the next few years! They are indeed almost unique. Absolutely true. I'd say this problem is orthogonal to being distributed or not (compare P4 or other old stuff). For our environment it's fairly convenient to have a bare repository on a shared folder: ideally we don't push short lived branches there - ideally we sync no more than a couple of times a week and push a full untagged branch with explicit merge commits. I suggest everyone to have a go; my experience with git is positive albeit I used to have a thing for Mercurial. Maybe I should have made clear that GitVersionTask stamps your c# executable with proper versioning by looking at the git. It isn't even just a property setting: you can inspect the result programmatically. Anyhow, I had been given unwelcome news today so I'll be slow on replying. Given my new schedule, I think I might just give up on GitVersionTask and go back on explicit version stamping. Inconvenient but I have already spent too much time in figuring out what's wrong there.