Jump to content
  • Advertisement

sergamer1

Member
  • Content count

    97
  • Joined

  • Last visited

Community Reputation

822 Good

About sergamer1

  • Rank
    Member

Personal Information

  • Role
    Programmer
  • Interests
    Design
    DevOps
    Programming
    QA
  1. I personally went for entities being simple ids with no pointers or references to components whatsoever. The main pros are it's simple and does not have the problem of needing to update pointers (therefore removing the risk of dangling pointers to dead entities/components). For example, if you want to reshuffle the components in a single system for more cache friendly performance, then the entities and other systems don't need to know because each system is completely decoupled. The main con is components and entities don't directly know about each other so a slightly more complicated way of communicating (e.g. an event messenger or the observer pattern) needs to be designed. Although there is the temptation to include pointers to components early on when everything is simple, as your engine grows and becomes more complicated, this becomes a horrible spaghetti mess of interdependent systems and components. Having ids with events/messages to communicate does not get more complicated. It can get slower if your messaging is not done in a sensible way, but this is more an optimisation problem for later (e.g. allow particular systems to subscribe to certain messages so the overall number of messages sent around is small). I don't know if you've read this online book before, but many of these issues are discussed here ( http://gameprogrammingpatterns.com/component.html )
  2. sergamer1

    The Poor Man's 3D Camera

    Yes, thanks for sharing that. Makes me (and probably a lot of other people) feel a little less stupid for getting stuck in similar design screw-ups. Although it's nice to get the design right the first time, I suspect everyone needs to do a certain amount of refactoring, redesigning and iterating before finally settling on the 'correct' answer. And those who get it right first time have either learned from experience with other problems or are just smart-ass geniuses! ;-)
  3. ok, so I circumvented the problem by using SDL2_ttf instead (which I was thinking about in the first place). I'm guessing the issue is locating the assets folder. SDL probably calls the relevant Android functions to find this out but you have to do this yourself with FreeType I'm guessing (which I obviously don't know how to do )? Anyway, I'll probably stick with this solution since I'm using SDL for other things anyway so makes sense to stay with the same library family. Even though nobody answered, thanks if you thought about it a little ;-)
  4. Hi guys, So I've been having some trouble with loading fonts in Android (using the NDK). I've successfully (I believe) compiled the FreeType library as a shared-object library next to some other libraries I am using plus my game/framework code. I am using the following commands to get things initialised. FT_Library ft; FT_Face face; FT_Init_FreeType(&ft); FT_New_Face(ft, filename.c_str(), 0, &face); This is what the FreeType tutorials (plus other various online pages) suggest using to get things going. When I run this code on my Linux laptop, it runs fine but if I run it on Android, it fails on the fourth line loading in the font. So I know the library is probably compiled and linked correctly or it would fail on the first or third line right? The other issue is where to put the ttf file. I've put it in the assets subdirectory, which is again where (almost) everyone online suggests putting it. Some suggest putting it in assets/fonts sub-directory which I tried (and didn't work) and also res/font (which ndk-build complained about while compiling so definitely doesn't work). I'm a little stuck now since I feel like I've exhausted all the obvious options so if someone with experience using FreeType on the NDK can tell me the magic formula for getting this to work, I'll be very grateful :-) . Thanks
  5. Just on my not-particularly powerful laptop (a cheapish Lenovo Thinkpad). I also have more stars than you (800-odd) which might slow it down a little more I guess?
  6. Yes, I just had a quick play around. Not saying this is so incredibly realistic but should be a little more so :-) Actually, it's perhaps a little 'boring' looking in a way since it's dominated by white, yellow and red stars but is closer to how it problably looks. The massive blue stars are usually located in young stars clusters and normally they die quickly before they enter the Galactic background (either fizzling out or exploding as Supernova). If you want to add other features like gas clouds and star clusters, then that is one thing to think about. Anyway, you seem to be making good progress so look forward to seeing some gas clouds soon ;-)
  7. Yes, that seems like really nice progress :-) . I have a few comments that maybe will help improve. A comment above about stars appearing more white in space is partly true yes in the sense they have a broad spectrum so the 'redness' or 'blueness' is not so apparent. So making them more white helps with the 'realism' (at least with the nearest stars; see my final comment below). Second, it feels like there are too many stars in the nearest plane and you can see they all move at the same speed a little too clearly which breaks the illusion slightly. I would perhaps reduce the density of stars here (although the distant ones seem fine for this). Actually, I wanted to say something about this also. This is incorrect but for the wrong reasons. It's true that there is redshift due to the expansion of the Universe but we can't actually see stars in other galaxies with the naked eye so all visible stars are in our own Galaxy. However, there is an effect known as interstellar reddening where gas/dust in the interstellar medium (ISM) absorbs preferentially blue light from distant stars making them appear redder. And since more distant stars have more ISM between us and it, they appear redder. This is a quite famous example where you can see an obvious gas cloud making stars redder. This is obviously a very discrete blob of gas, but this happens in many directions on large-scales so I would make the near stars white/yellow/blue (depending on mass) and the distant stars more and more red if you wish to mimic this kind of Galactic-fog effect :-)
  8. sergamer1

    Android NDK logging (with SDL)

    Yes, it worked first time! Brilliant! :-). Thank you for your help with that. Yes, I already had some logging macros exactly like this but wrapped around the SDL_log functions instead so it was pretty trivial to exchange them for the Android log functions. I rather suspect the SDL_log functions are probably wrappers around this android function also in some way but wasn't clear getting them to work as I wanted. Anyway, thanks again :-)
  9. sergamer1

    Android NDK logging (with SDL)

    Ahhh, ok. I've been trying with Logcat and the problem I said was it just tells you everything you didn't want to know what is happening. But if there's a way to tag and filter the messages, then I think this solution alone would be good enough for my purposes. Thanks for the suggestion :-) Is it simple enough to describe here what to do? Or are you talking about really basic stuff, like adding a string/tag directly to the output and then grepping the file for the tag? :-) No, definitely not. The tagging solution (whatever form it takes) will be simple and workable enough for me (assuming I can get it to work). I saw one or two examples on stackoverflow where using the Android log directly via NDK (so avoiding SDL completely) seemed relatively straightforward. I'll give it a go if SDL gives me any (more) trouble with this. Thanks :-)
  10. Hi everyone, I'm having some issues adapting my C++/SDL framework to use on Android. I'm using the NDK and installing directly onto my tablet via the command line and normally it works fine but sometimes of course it does nothing and it's a pain to debug. So I thought about adding some simple logging functions so at least I can get some basic idea of what happens. But it seems creating logs in Android is tricky also. So a couple of questions. 1) Is it correct that you can only use a predefined set of Android logs (i.e. an info, debug, verbose, etc.. log)? So it's impossible to make your own log-file just from your application and dump all output there to analyse? Or did I miss something? 2) Since I was using SDL, I tried using their log functions but it seems to dump direct to one of the main logs (containing basically everything) so it was not much help. SDL also has functions to generate internal files for game save data, etc.. So I hoped I could adapt this to make my own log except these files are private and cannot be read, at least not in the default mode. Is there any way around this that anyone knows, where I can download an internal private file to my laptop to analyse? 3) Is there an easier solution I've missed? Thanks in advance :-)
  11. Yes, I was pretty confident the simple prescription would still look pretty decent and not too uniform so glad to see I was not talking rubbish! ;-) Happy you're making progress on it anyway. Sure, I had a couple of things to say about the colours. Although some are fine, some are not very 'star-like' should we say :-) Stars typically go through a range of colours like brown-red-orange-yellow-green(ish)-blue in order of increasing mass (i.e. brown dwarfs are the smallest that are visible and blue supergiants are the largest ones you can see before they go supernova anyway) In principle, other colours are there too but these are the typical ones. The other thing is they seem to fade in-and-out, almost like twinkling in the night's sky. Except star's don't twinkle in space :-) (because it's an effect you get only with an atmosphere). Of course, I am just saying what is realistic whereas maybe you just want what looks best ;-) Okay, gas clouds are a whole other ball-game! Their form is highly irregular and not described by some simple equation (unfortunately). When astrophysicists try to generate such density fields, they usually try and produce some kind of fractal density field (i.e. with fractal dimension less than 3 so it has holes and other structures). Maybe you should consider something like Perlin noise (https://en.wikipedia.org/wiki/Perlin_noise) since you'll presumably only be generating in 2d. Many people generate irregular shaped profiles, such as mountain ranges or islands, using Perlin noise, and I think this the route to take. I've seen other people try stuff like this (i.e. interstellar gas clouds) in the past, although I'm not sure what method they used. If I find something that's useful, I'll post it here! :-)
  12. Yes, I was thinking more a 3 or 4 layer parallax starfield, but that's your preference of course. The key to making it work is the further the starfield, the slower it moves in parallax, the more stars it has and the dimmer those stars are. This should in principle be quite easy to do I think. If you have a uniform (on average) density of stars, then the simple random sampling works. But let's say you want some structure, like the spiral arms of the galaxy, or perhaps some dense star clusters spread around? Then you can either tabulate this or make a function of this density field of stars. And then you perform the Monte-Carlo rejection sampling over the density field, and abracadabra, you have a more interesting density field :-) . Other possibilities include perhaps Perlin noise or some other combination of simple density modes. However, like I said, I think you'll find the uniform random (with different brightness parallax layers) to be more than adequate! ;-)
  13. Sorry, I just realised you did say the word 'random', missed that one! :-) . But actually my point about the brightnesses still stands. A 'random' distribution of points does not actually make a 'uniform' distribution of points. It follows a Poisson distribution with clumps and voids naturally forming. Adding the brightness factor I think will accentuate this and it will be a pretty decent effect I feel. Of course, if that was not good enough, you could do some other things, like create some density function across the sky. Let's say it was sinusoidal (yes, that's crap but just for example). Then you can use something called Monte-Carlo rejection sampling. You get some (on average) underlying density field plus an element of randomness on top. But I think you should try the simple random x/y/brightness approach first. I think you'll find it is better than you might first think.
  14. Hi there, I thought I should start with the obvious suggestion; have you tried simply a random distribution of points? Remember that stars do not all have uniform brightnesses so 2d random positions plus a random brightness factor would probably give you a nice effect I would have thought (and pretty simple to do). Also, what do you mean by 'slowly animate'? I don't know the game in question, but do you mean as you move around the x-y plane and you see the stars in the background move with some sort of parallax effect? Because if that's the case, my random suggestion above still works but in that case, the brighter the star, the closer it is so the movement parallax will be bigger and pretty easy to generate I think. Or maybe I'm thinking of something completely different to you :-)
  15. sergamer1

    Gravity systems?

    Okay, that's one solution indeed!  :-)   I guess it's important to remind yourself, what are you trying to achieve.  Are you trying to model the actual physics or make something that LOOKS real for gaming purposes?  If the latter, then tricks like this or softening which was mentioned earlier (which is used in many 'real' science/astro simulations btw), are perfectly valid.  Regarding the suggestion about adaptive timesteps, this is again something you would definitely do to follow the physics more accurately but then you have unpredictable rates since your simulation slows down whenever two stars get close and then speeds up again, all very jerky and unstable.  So a fixed timestep works fine if your not bothered about getting things right with close interactions.  But if you want to model the physics accurately (out of some scientific curiosity for instance) then definitely consider it.   The advantage is you get more accurate integration of the orbits (actually important for both scientifically accurate simulations and for making it look better) since leapfrog/mid-point gives second-order errors compared to Euler integration which is first-order.  A leapfrog integrator is also a special kind of integrator (called a symplectic scheme) which has wonderful conservation properties which amongst others preserves circular and elliptical orbits (e.g. planets or binaries) very well.  The thing is, all these schemes are as expensive as each other, just one force computation per timestep so in that case you would use the better one right? :-)    I'm going to have to disappoint you on this one.  You are of course correct for two bodies.  This problem was solved by Sir Isaac Newton some 300+ years ago :-) .  And in the intermediate centuries, everybody and their cat has tried to add just one more body to solve the so-called 3-body problem.  But there is no general solution I'm afraid that can be used like you hope for.  There are various special so-called 'restricted' 3-body problems where the motion of 1 body is limited in some way so it becomes a 2-body problem again or has some special solution for some configuration.  But in general, and especially when this becomes 4, 5 ... N bodies, you have to do the numerical integration I'm afraid!  This is one of the step-ups from linear/soluable equations to non-linear equations.  All the 'geniuses' of yesteryear solved the 'easy' linear stuff :-D and left all the difficult non-linear stuff to our generation!  :-/   Oh well ...    Regarding the oct-tree, I'm still a little unsure if you really need it for gravity integration (for the reasons discussed earlier about the ~1000 body limit).  However, if you want to model some kind of larger Universe with large-scale structure and then 'zoom' into galaxies and further, then having a tree structure to organise this data hierarchically is obviously a good thing.  If you can combine it with helping to compute the gravity, then great but I'm still unsure if you'll get that much benefit while maintaining 30/60fps.
  • 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!