Advertisement Jump to content
  • Advertisement

Programmer One

Member
  • Content Count

    7346
  • Joined

  • Last visited

Community Reputation

747 Good

About Programmer One

  • Rank
    Advanced Specimen

Personal Information

  • Interests
    Business
    Programming
  1. Programmer One

    Android Sprite Caching

    Generally speaking, it's about reducing overall memory usage, not having to load a bunch a small files from "disk" and making the APK smaller. Additionally it's also about cleaner resource management. The tool I'm using will produce a single image with all my assets alongside a JSON file which tells me where those assets are. Also, it will nicely group all my animated frames so I can just find animations by their group ID. Having to manage and load individual frames, specially several animated frames just seems a bit of a nightmare. I might give it a try, considering it wouldn't be that difficult to check. The post I saw on stack overflow was from August of this year though, so I'm not holding my breath. Yeah, when I was looking around, I saw either people just strait blitting directly from the atlas, or cutting out all the individual images into their own bitmaps. I don't think that scales well given the overhead for every sprite. Maybe for super simple games. I really want to make the move to OpenGL, but I've already spent way too much time on implementing other things. I'm trying to keep this project on a schedule and reduce scope creep. My goal is to release this little game I'm making by a set date. After thinking about this problem a bit more, I think I'm just going to drop the rotation support from the engine until I move to OpenGL. My current game doesn't need to rotate any of the sprites anyway, so rather than spending more time than I want to, I'm just going to cut back the feature set, and keep things simple in favor on Canvas's limitations.
  2. Programmer One

    2D Android Sprite Caching

    I'm currently writing a 2D game engine from scratch for Android. The first iteration of the engine is just going to use the Android Canvas view for drawing. At some point, I want to support OpenGL ES - but not until I finish this first project (which is a very simply game based on this engine). Right now, I'm dealing with Sprites and I've encountered a design challenge that I'm not entirely sure which direction I should go. For the sprite bitmaps, I've decided to go down the sprite atlas route (as opposed to individual image files). I'm using Texture Packer and I've written a custom JSON exporter. I didn't really want to limit myself too much, so I decided I'd support sprite rotation and trimming in order to save as much space I can in the atlas. I backed off from supporting polygon trimming for now. If you're unfamiliar with Texture Packer, it's essentially a tool that will allow you to import individual sprite frames, organize them into folders and then have the application generate a sprite map and corresponding coordinate data file. This application supports trimming any blank (alpha) space around the sprite images in order to pack them closer together. It also supports rotation if it makes the image fit better. What I'm trying to figure out now is how to deal with loading the sprite image data. Currently, I'm at the point where I can deserialize the JSON map data into "Sprite Frame" objects. These objects contain information about each frame. My format allows grouping of sprite frames in order to organize frames that correspond to the same animation. In essence, the sprite frame object has: The original (untrimmed) size of the sprite image. The original position of the sprite image within it's bounding box. The rect of where the image is in the sprite atlas. A flag indicating if it had been trimmed. A flag indicating if it has been rotated (CW). This will give me all the information I need to draw the image onto the Canvas. If I didn't support all the other fancy features I want (packed rotation, trimming) and pre-transformation (i.e. mirroring a sprite so I can reuse it for things like changing the walking animation without having to pack in more sprites), then drawing the image from the sprite atlas onto the canvas would be as simple as a simple Canvas.drawBitmap([Source Bitmap], [Destination Rect], [Source Rect]). But, since the image I'd be drawing MIGHT have been rotated, trimmed or otherwise transformed, I can't just simply blit it onto the Canvas. I'd first would need to apply some transformations in order to "undo" changes that were done during packing. This means I would need to either: Slice out the child image from the sprite atlas into a new bitmap, and apply the "unpacking" transformations (i.e. rotate back, realign, etc). Apply a transformation to the Canvas itself. (I don't think I want to go down this road since I've read that transforming the Canvas tends to be rather slow). So, I'm probably left with having to create smaller bitmaps from the sprite atlas and then keep those in memory for as long as I would need them. So, for a single sprite character, I'd be looking at around 36 sprite frames (9 different animations, each with 4 frames). What I'm concerned about is memory consumption. So now I'm thinking: I should read in all the sprite bitmaps from the sprite atlas and shove them into an LRU cache. This means all the sprite image data is now in memory, all ready to go for whatever animation sequence and frame I want. Once I'm done with the atlas, I dispose of it and just work with what I have in memory. I can perform this caching when I load levels and then clear items from the cache that I no longer need. I should just keep the sprite atlas, blit directly from that onto the canvas, and get rid of the fancy packing features so that I don't have to process any transformations. The only problem with this approach is that I will also have to shelve shearing and rotation on the sprite object itself. TL;DR: Am I being overly memory conscientious or having a couple frames of sprite data in memory not a super big deal?
  3. Programmer One

    So who is still around these days?

    Sup.
  4. Programmer One

    How stupid was this?

    Should have argued the ticket, say you suddenly weren't feeling well or something. Now that you have it, too late. Pay the ticket and don't do it again. [/quote] It's definitely not too late. The signing the ticket is not an admission of guilt, and he could still make this argument in court. [/quote] The place to get the ticket dismissed is with the cop. It can be done in court, but it just got 10x more difficult - especially if the officer shows up.
  5. Programmer One

    How stupid was this?

    Should have argued the ticket, say you suddenly weren't feeling well or something. Now that you have it, too late. Pay the ticket and don't do it again.
  6. Programmer One

    Looking at source code makes me sleepy! Help?

    Stop looking at Perl
  7. Programmer One

    Duke Nuken Forever Coming Soon!

    Unless you've been on these forums for like the past 10 years, every year that DNF hadn't been released, a thread would appear on April Fool's day saying it has or that it will be. We've already had a real DNF discussion here a little while ago. This type of thread, however, is the last of its breed.
  8. Programmer One

    Duke Nuken Forever Coming Soon!

    Haha, April Foo....uh....wait a minute....damn. RIP DNF Released Soon April Fool's Joke. 1997-2011
  9. Programmer One

    What brings a smile on your face?

    Facial muscles.
  10. Programmer One

    You know you're a nerd if...

    ...you start a "You know you're a nerd if..." thread.
  11. Programmer One

    [as3] Gravity

    Have a look at this thread: http://www.gamedev.net/topic/121472-jumping-algorithm-kinematics/
  12. You need to set easily achievable goals. Going from learning *some* C++ to writing a game engine (of any degree) is a bit like "reading something about heart surgery on Wikipedia" to "conducting a heart transplant in a surgery room." If you set your goals out too far, you run the risk of never achieving them. Maybe writing a game engine could be a long term goal, but start setting some smaller, realistic goals first. For example, now that you have a grasp of a language, learn about file I/O and object serialization. Games load resources from files, so figure out how that's done.
  13. Programmer One

    The Epic Thread Of Awesomeness

    Piss
  14. Programmer One

    Gdnet Black (Alpha)

    This black theme (albeit still work in progress) is total, absolute, complete and utter crap. Yet, it is waaay better than the standard theme.
  15. Programmer One

    What Does Everyone Think About The New Site Layout?

    Hey, post ratings. That's cool. Also, where the hell is everybody setting custom avatars from...?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!