sergamer1

Members
  • Content count

    95
  • Joined

  • Last visited

Community Reputation

821 Good

About sergamer1

  • Rank
    Member

Personal Information

  • Interests
    Design
    DevOps
    Programming
    QA
  1. 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 ;-)
  2. 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
  3. 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?
  4. 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 ;-)
  5. 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 :-)
  6. C++ 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 :-)
  7. C++ 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 :-)
  8. 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 :-)
  9. 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! :-)
  10. 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! ;-)
  11. 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.
  12. 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 :-)
  13. 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.
  14. Gravity systems?

      Yes, I did read through some of them.  I have to say most of those are completely irrelevant to the problem of the formation of structure in the Universe, hehe :-) .  But having a broad knowledge is always a good thing before embarking on an epic project.  However, its also not good to get lost amongst all that since it might be tricky figuring out where on Earth do you start (believe me, I've done the same thing).     Okay, first of all the large-scale filamentary structures that develop in the Universe are kind of static in a way, although they are more the hubs of growth of galaxies and clusters of galaxies.  Take this famous simulation of the Universe, the Millennium Simulation (https://wwwmpa.mpa-garching.mpg.de/galform/virgo/millennium/#slices);  if you look at the slice images of different redshifts/z-values (which is the same as different ages of the Universe).  You can see the filaments start very thin but then grow and accumulate mass but they don't really move around that much.  What you want (if you really want to mimic the evolution of the Universe) is something that starts roughly uniform and then filaments grow out of the background, gravitationally attracting more and more mass creating large galaxies and clusters.  And the trick will be to do this without actually computing all that expensive gravity.   About your 50 particle run, that actually looks exactly what these simulations should look like with basic gravity so guess you're on the right track ;-) .  You'll occasionally see stars get ejected and also binary stars (you can see the two stars orbitting each other almost getting kicked out).  Here's a famous (in Astrophysics) example with just 3 stars but has similar features to yours (http://www.ucolick.org/~laugh/oxide/projects/burrau.html).   But back to the issue of computing for more bodies.  The reply above is correct in that you would need some kind of tree to efficiently compute gravity for larger numbers.  However, you'll only need this when the numbers are of order 1000 or more and by this point, it takes (on a single CPU) about 0.01s to compute all the forces for all bodies.  If you want a game running at 30/60 fps, you're already near the limit so it's questionable whether using a tree is worth it.  Also, as I said in my previous post, this is the route to actually computing the real physics terms which is NOT what you want to be doing!  You want to be able to mimic these so it looks real rather than doing all the hard work.     I was trying to make this point yesterday (probably not well enough) with the globular clusters.  Globular clusters have 1,000,000s+ of stars and there's no way in hell you could model that with computing the real gravitational force.  But these clusters have a simple average density and potential field (given by the equations in the wiki article) and using that instead will give you the motion of the star around the cluster, so 1 equation not 100000...s with real gravity.  There are sophistications that can be made of course, such as finding if there are any nearby interactions with stars to model scattering and ejections but these are the icing on the cake really!  I'm a bit busy atm, but maybe I'll put together some pseudo-code for you to see what I mean because it's tricky stuff.  But it'll have to be in a few days sorry!   In the meantime, don't drown on all the knowledge!  :P
  15. Gravity systems?

     Yes, I didn't feel like you were planning that from your original post but the way the thread was going, it seemed like things were pointing that direction which I thought I should just point out right now is a very bad idea, unless you want to train to be an Astrophysicist yourself :-)   So, the Universe is a pretty big topic to discuss so where to begin :-) .  Newton's law of gravity is certainly useful for very basic motions, such as how planets (or moons or rocket ships) may orbit around stars (or other planets) but will be too expensive if trying to model larger systems with more than a dozen (or perhaps a couple of hundred) objects.  What you should be looking at is developing (or reading about) simple models that use simple mathematical equations to represent the gravitational potential field or simple combinations and then your physical objects (e.g. galaxies, stars, etc..) move as test particles (https://en.wikipedia.org/wiki/Test_particle) in these potential fields rather than computing the full insanely expensive gravitational.  Let's take a basic galaxy as an example.  It contains A spherically symmetric halo of dark matter.  It doesn't do anything interesting really but holds the galaxy together gravitationally and can be approximated by a simple equation (e.g an NFW profile, https://en.wikipedia.org/wiki/Navarro%E2%80%93Frenk%E2%80%93White_profile) A halo of old stars, many contained in very old massive clusters called globular clusters.  The globular clusters can be very easily modelled with something called a Plummer potential profile (https://en.wikipedia.org/wiki/Plummer_model) The gas in the galaxy (often called the Interstellar medium or ISM) lies in the disc of the galaxy but often concentrated in spiral arms, as like the classic picture of galaxies  (There's no simple article for this sorry, but maybe this helps : https://en.wikipedia.org/wiki/Gravitationally_aligned_orbits) The gas is compressed in these arms leading to new stars forming from the gas.  The density of gas and the formation of new stars has several empirical relations, like the Kennicutt-Schmidt relation, which allows you to approximately model how this happens (Sorry again, no simple article on this).  These stars then spread into the disc of the galaxy and move around in (approximately) circular orbits around a spiral potential. And that's just to model a typical everyday spiral galaxy that you might find.  If you want to model how this forms (in a hand-wavy way) from the big bang, then you need to consider the large-scale picture like the formation of Galaxy clusters, how these protogalaxies merge and form the next generation of galaxies.  That's not quite my own field but I know enough to know it's possible to do in some nice approximate way like you are probably suggesting.  You could for example, model a Universe with various smaller galaxy seeds (but not too many unless you want the performance issues again).  There would need to be some underlying filament potential which describes the large scale structure of the Universe (e.g. https://phys.org/news/2014-04-cosmologists-cosmic-filaments-voids.html) and then your test particles will move towards them to mimic the natural formation of the large-scale structure.     As you might guess, there is so much to go into this (and even I'm not 100% sure of all the steps) but I hope this little post has helped explain a possible path to modelling a Universe on the cheap!  ;-)   Haha, guilty as charged!   Never thought I was hiding though!  :P   Hmmm, unfortunately some of these 'basic' things don't have nice pages for the layman like wiki.   There's a ton of astro articles, such as University pages, if you type 'King cluster profile' into google but not sure which one is good to recommend.  But there's hopefully enough info and links here to help for now!  ;-)