• Content count

  • Joined

  • Last visited

Community Reputation

198 Neutral

About futlib

  • Rank
  1.   That sounds good, that way I'll be able to keep memory usage under control.   Still, I see a notable lag when loading just one of the larger images on older systems, so I really think I'll have to do some preloading with a proper loading screen. Still not sure which approach to go with for that.   I'm somewhat back at square one in that I'm again considering to have the scene preload everything it needs itself. Widgets don't own their resources anymore, so it's not as difficult to implement as it was when I started this thread. I can just clear the cache after each scene (maybe having a global area with things that are never cleared).     Well, the game runs on Android, so disk storage is not that abundant :) Good ideas, I'll look into these if downscaling isn't sufficient.
  2.   Sure. However, note that the virtual memory size I reported is the vsize returned by top on OS X. It's 2.4 GB for the Python interpreter and even simpler tools like bc. Anyway: The screen/scene we're talking about is where the player can create his character. He can chose from various variants of body parts (hair styles, eyes and such), all in all there are 63 variants right now. To select a variant, the player touches one of the preview images, so we also have 63 preview images which are scaled down to a width of 500 and cropped to a maximum height of 500. And there are also 63 generated images for the button down effect of the same size. The real body part images are larger, averaging around 1500x1500. Add to that a 3200x1800 background image and some less noteworthy UI graphics and that's about it. The memory usage I reported earlier was after loading all of the preview images and some of the larger images. If I load absolutely everything, the resident memory is at almost 1 GB and the virtual memory at 3.8 GB. However, much of the larger images are still in the resolution in which the artist provided them, sometimes twice a big as necessary, so I'll be able to cut that down a bit I guess. I just wrote a script that downscales everything for a resolution of 2000x1125 (factor 0.625), which would suffice on most screens. Virtual memory after loading all the preview images and some of the others is down to 2.8 GB, resident memory to 150 MB (was 2.7 GB and 280 MB respectively before), after loading everything (some of which is still twice as big as necessary) it's at 3.1 GB virtual memory and 500 MB resident memory.
  3. Just implemented the texture caching. Unfortunately, my memory estimates were quite off as I was doing them based on the size of the compressed images... In reality, having all images in memory causes a resident set of around 280MB, virtual memory usage being around 2.8GB. Considering that we'll probably end up with three times as many images, this seems way too much.   So I suppose I'll have to look into per-scene preloading. The options I considered so far still apply, slightly altered:   2a. Have a mapping between image IDs and image paths, with a separate section for each scene 2b. Have a list of images to preload for each scene 2c. Preload all images in a specific directory at the start of each scene   2c seems pretty unattractive now... Yet I can't imagine that most games handle this by simply hard coding/mapping all image paths (2a/2b).
  4. Yeah, a cache sounds good, I think I'll go with that. But I still need to figure out which resources to preload, thoughts on that?  
  5.   In Qt, images are loaded as soon as a QPixmap object is instantiated, causing a lag like the one in my game when lots of large images are being loaded. But anyway, I agree, the widgets shouldn't own the resources. I do have an asset loader already and I can move the image loading into it, and also add caching.     I'm not afraid to preload them all, I think that's going to be necessary. It's only going to be 100-200 MB, so that should be fine even on ancient systems. The OS will page unused resources out anyway. I was thinking that it may be better to have a loading screen for each scene, but I suppose that's not really necessary at this scale.   My problem is that I can't figure out how to preload everything, I never had to think about this before working with less/smaller images. Only the widgets know which images they need, so I see only two options:   1. Instantiate all widgets upfront - they'll load their resources 2. Figure out which images to load without consulting the widgets   Your suggestion sounds like option 2, and it does indeed seem better. Now I'm wondering how to implement that, seeing three options:   2a. Have a mapping between image IDs and image paths - use the image IDs in widgets, preload all the images from the mapping file on startup 2b. Have a file that lists all the resources that should be preloaded 2c. Just load all image files in the directory   2a Seems tedious - I'll have to add every single image file I use there. 2b is similarly tedious and on top of that error prone - it's easy to forget. 2c involves no manual effort, but I have to make assumptions about what to load (e.g. every file name ending with .png) and it may load too much if there are unused resources.   How is that commonly being solved? Considering that many games have loading screens per scene or level, how do they figure out which resources are required upfront?
  6.   I'm not convinced that makes things easier in my case. My game is mostly GUI, so I have widgets and screens rather than entities and scenes. And having widgets draw themselves is ubiquitous in UI frameworks.     That sounds like my option 2. Can you think of a better way to implement this then what I came up with, the big mapping? I've pondered this quite a bit, but unless I create all widgets upfront, I cannot possibly know which images are going to be required.
  7. I'm working on a 2D game and am starting to see some short lags caused by image decompression (I'm using rather large graphics to support high resolutions). I suppose I'll have to load all my textures upfront and show a loading screen, now I'm wondering how to best go about this. I can think of two approaches:   1. Instantiate all entities for a scene when the scene is being created (Every entity is currently loading its own texture when it is being instantiated, so that should do). The manual effort seems a bit error prone though (easy to forget), and might mess up the code a bit.   2. Have a mapping from image paths to image IDs and use the IDs to load images in the code. That way I can load all the image files when the game starts. But it's tedious to add a mapping for every image I use, and not very flexible as I cannot have loading screens for individual scenes.   I'm not particularly enthusiastic about either approach. How is this commonly being solved? I can find some literature on this that focuses on huge 3D games, but that doesn't seem to apply too well to my small 2D game.
  8. Thanks, I'm quite happy with this now.   I'll stick to OpenGL 1.4 if I can (don't need no fancy graphics but I want to support old hardware as much as possible), I'm quite sure antialiasing will make the fonts look good enough.
  9.   Fixed this, now it looks much nicer (but could still do with antialiasing).   However, this is kind of a hack I came up with to zoom in on all aspect ratios less narrow than 16:9. My reference resolution is 16:9, but I don't want black bars on 5:4, so I basically just zoom in until there are no bars anymore (that's at 2250x1800 for 5:4) Without the glScale hack, everything gets stretched. Any idea how to better solve this?   Edit: Came up with a better hack (I think): I'm adjusting the reference width for the aspect ratio, i.e. I end up with a reference size of 2250x1800 for 5:4, which I use for the ortographic projection matrix. Means I end up with a dynamic reference width, but that's fine since I can account for that in the UI code.     That's a topic I avoided until now, but I suppose I'll dig deeper into it. OpenGL seems to offer a ton of options, fortunately.   Anyway, rather relieved that the approach I sort of made up myself is apparently common Got any advice on the font issue? Should I just scale the damn fonts down or should I try to make FreeType render them in a different size based on e.g. the vertical resolution?
  10. I want to support both low-end desktop resolutions (like 1024x768) and pretty large resolutions (that's 2880x1800 for the 15" Retina MBP).   My basic approach is this: Use a large reference resolution (3200x1800) to position/size elements (it's a simulation game that's basically just GUI, so there is no world space, just screen space) Use large artwork, specify its size relative to the reference resolution so that it's scaled at runtime Draw everything scaled down to the actual resolution (using OpenGL's glScale) But I'm not sure if it's a good approach. It's not a huge game, so I don't think asset size is going to be an issue, but I see some other red flags: It looks pretty scruffy on lower resolutions like 1280x720. Like as if there's no anti-aliasing. I suppose I could fix that with OpenGL, but it makes me wonder whether I should I render fonts (using FreeType) at huge sizes like 160 pt, just to scale them down again later. That wastes both memory and makes them look worse then they could. I'm thinking of not scaling fonts and instead calculating font sizes based on the difference between reference resolution and actual resolution, but that's not going to be very exact. Is there a better approach than what I came up with?
  11. Thanks for all the advice, I've pondered quite a bit on this.   I've decided to get Mathematics and Physics for Programmers now. It covers a lot of ground I'm already familiar with, but it really seems like a comprehensive reference of all the basics, explaining them much better than Wikipedia (which I usually turn to for refreshers). And it really covers a lot of ground, from what I've seen pointing to more advanced books for further reading. But it does seem to cover all the things I really need right now.
  12.   On my list before I narrowed it down, is what I meant But sounds good, didn't notice it covers collision response. And the other books don't allocate many more pages to that anyway. It's definitely on my list now. And since it's apparently quite famous, it's a good candidate, too.     You have both Mathematics and Physics for Programmers and Mathematics for 3D Game Programming and Computer Graphics? I havent read the former (obviously), would you say its too basic for someone with a CS degree? Or is it still something you refer back to occasionally?
  13.   It was in fact on my list, but I thought it didn't cover physics. Just saw that it does. Would you say that it manages to bring across the basics well? It's only 20 pages on linear physics, doesn't seem much. I don't want to write the next Box2D, I just want a solid foundation. It has a trigonometry reference, that's a plus. Would you generally say it's useful for 2D games? Do you have a more basic math book accompanying that one?
  14. I've been pondering which math/physics basics book to get for hours now. My math basics are quite good from my BSc in CS. It's been a while though, and I would like a reference of things relevant to game development. My physics basics are not very strong. I know some basic mechanics but that's about where it ends. I'm mostly working on 2D games. I've worked on 3D games and would like to learn more about the graphics pipeline and rasterisation and such, but I can still get a specialised book on that. I'm looking for information on collision detection and response algorithms. There are several promising books, I've narrowed it down to just two:   Mathematics and Physics for Programmers Very basic, starts at grade school level More of a textbook than a reference, it seems Covers all the relevant basic math topics: trigonometry, calculus, linear algebra Seems to cover the relevant physics basics, but I can't tell for sure Covers a broad range of topics, even some game theory and AI Has a chapter on tile-based games, which is probably quite relevant to me Uses lots of IMO rather difficult to read pseudo code Uses slightly weird terminology, e.g. they're talking about "squares" instead of boxes when discussing collision detection, and of "collision resolution" instead of "collision response" (which gets much more relevant hits on Google at least) Not well-known authors, doesn't get much praise Essential Mathematics for Games and Interactive Applications Seems appropriate for my level Seems to use proper terminology Does not cover trigonometry or calculus, doesn't even include a reference of the trigonometric identities Covers linear algebra in much more depth Covers rigid body physics Has a highly interesting chapter on interpolation Covers the graphics pipeline and shaders Semi-popular authors, gets considerable praise It's not on gamedev.net Books for some reason I really am torn. Getting both seems wrong, as they cover much of the same ground.   MAPFP seems to be less known and less sophisticated, yet I could use a refresher on calculus and would like my reference to include trigonometry. It also has some interesting hands-on topics.   EMFGAIA seems more appropriate for my level, yet covers various things I don't really need right now, working on 2D games. But it seems to be more industry-connected, and at the same time more scientific/accurate.   So, what do you think, which one should I get? Or can you recommend another one appropriate for me?  
  15.   Well, that's only half true, still have to figure out how to deal with NPOT textures with libpng :( That's mainly why I'm wondering if I want to go with that approach, to know if it's worth tearing more hair out before I start tearing :)