• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Galaban

Sprite class and memory effeciency

14 posts in this topic

I'm currently coding a basic 2d rendering system intended to be used as the base for a tile-based strategy game I plan to make. The beginings of it are implemented, and there are notes for future sections. It's nothing fancy, but it handles render batching to minimize state changes, basic effects like rotation, scaling, frame animation, and allows most properties be animated using arbitrary animation curves.

However, I've come to an unfortunate realization about the design of my sprite class: given that the intended project is a retro turn-based strategy game, I know in advance that the non-basic fields of the sprite class will be unused by 95% of the sprites or more (at any given time). Almost none of them will be scaled or rotated or colorized or have motion blur or even animated outside of brief periods when actions are performed. Otherwise, they are largely static. So, in the most straightforward implementation, every Sprite would have fields for scaling, rotation, colorization, and multiple other properties, when I KNOW that this will be wasted memory at least 95% of the time. What can I do about this? Any recommendations?
0

Share this post


Link to post
Share on other sites
If you're programming for a PC use then this is a non-issue since you have plenty of memory to spare.
But you can make the sprites extendable with whatever you need.

Edit:
Further more, pre-optimizations are the devil. Fix it when it becomes a problem.
I have no idea where you get the number 95% from.
A sprite class in general takes up a couple of bytes, the big memory hogs are the textures.
0

Share this post


Link to post
Share on other sites
[size="2"]Molle85 is right -- write your game. Stop worrying about optimizing at this point. A few extra bytes per sprite -- nothing on modern machines. This isn't the 8bit days when you'd put code in the spare few bytes at the end of scanlines because you're so short on memory. 1000 sprites x those extra bytes... still only a couple of K. Load a DLL and it'll probably waste that much space.It'll be a problem at some point -- maybe when you port it to mobile phones or something. But worry about that later. Code doesn't have to be perfect or brilliant. It only has to be "good enough".

Important rule of software engineering; "When in doubt, use brute force". It was coined by [/size]Ken Thompson to describe his philosophy for developing UNIX. That's why so much of UNIX is lookup tables or singly linked lists. Really simple structures that turned not to need optimising. They'd probably never have finished UNIX if they'd worried about optimising all of them up front.

0

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1314684074' post='4855321']
What language are you using?
[/quote]

Java.


Thanks for the replies and I do appreciate the sentiment. I admit that I have a some recurring issues with potentially-unimportant optimizations, but I am particularly bothered in this case by the fact that the significant majority of the class's members would be unused in the general case. It's not a matter of fussing about trimming 10% off the top of something, but rather that 90+% percent of it would be 'waste'. A rough calculation suggests something between 100-200 bytes of overhead for rarely-used properties (depending on exactly how many of them I implement), and only about 16 bytes for the ones that everything needs all the time. Such an imbalance really strikes me as wasteful and sloppy, but several schemes I've considered for reducing the memory footprint (like encapsulating related groups of properties in other classes, and letting the Sprite maintain null references if it doesn't use that type of property) significantly complicate the logic and don't always save that much memory either, due to needing to store object references and per-object overhead.

As for the target hardware, I'm aiming for at least 5 year old computers (and really, actually aiming older than that, but haven't been able to even [i]find[/i] one older than that in person, to benchmark stuff against) And yes, I realize that there's probably no realistic way to end up with a memory footprint too large even for that, but I don't feel it's good practice to accept too much 'padding', if one can avoid it.

I was just wondering if there were some conventional strategies for this sort of thing, or whether it really was a typical compromise to just throw every conceivable type of property or effect that requires specific tracking into the sprite class, and accept the wastage.


[quote name='Katie' timestamp='1314691594' post='4855348']
[size="2"]Code doesn't have to be perfect or brilliant. It only has to be "good enough".[/size]
[/quote]

This is probably more true than I'm comfortable internalizing, I admit...
0

Share this post


Link to post
Share on other sites
[quote name='YogurtEmperor' timestamp='1314776011' post='4855783']
Someone gave ApochPiQ’s post a -1? Even though that is the correct solution.
[/quote]

Just wondering, but how exactly do you give a post -1 points? All I see is a "Like" button...
0

Share this post


Link to post
Share on other sites
Only certain users can see the thumbs down button, this includes mods and some other users. For the non-mods I don't know what the criteria for being able to use them are.
-1

Share this post


Link to post
Share on other sites
[quote name='Galaban' timestamp='1314765690' post='4855754']
Such an imbalance really strikes me as wasteful and sloppy[/quote]
You're using Java. The most memory inefficient platform there is.


Instead of worrying about fixed per-object member overhead, minimize allocations to some reasonable extent. The bulk amount of memory doesn't really matter all that much, considering JVM requires about 4x the working set to run without GC hogging up all the resources. Or, if you have 250MB textures (somewhat permanent), expect JVM to require 1GB of RAM. If your entire overhead of this state is then 100MB, it's simply absorbed in the reserve.
0

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1314771978' post='4855774']
Can you factor the most-commonly used members into a base class or three, and then use subclasses for the special cases that need more data?
[/quote]

I considered this. The main issue in this case is that while I know that most sprites will not need any extended properties at any given time, I don't easily know in advance [i]which[/i] of them will need them. For example, consider a motion trail effect that can be applied to any moving sprite. This is only used for certain special attack and spell animations, but these could theoretically apply to [i]any[/i] creature or projectile. It's just that, in practice, 99% of creature and projectile sprites will never use it. The same thing applies to a great many of the extended properties.

Given that I can't make very good advance judgments about when to give a creature a (for example) BasicSprite over an ExtendedSprite, this would seem to require a way to construct an ExtendedSprite from a BasicSprite (and vice versa), and convert a creature's sprite from one to the other whenever advanced effects are applied to it or when those advanced effects end. This... seems unpleasantly cumbersome, to say the least.


[quote name='Antheus' timestamp='1314807572' post='4855951']
You're using Java. The most memory inefficient platform there is.[/quote]

The fact that a platform itself is inefficient doesn't mean that one should disregard efficiency entirely. If anything, it might be even more important since there are many ways to incur overhead.



[quote name='Antheus' timestamp='1314807572' post='4855951']
Instead of worrying about fixed per-object member overhead, minimize allocations to some reasonable extent. The bulk amount of memory doesn't really matter all that much, considering JVM requires about 4x the working set to run without GC hogging up all the resources. Or, if you have 250MB textures (somewhat permanent), expect JVM to require 1GB of RAM. If your entire overhead of this state is then 100MB, it's simply absorbed in the reserve.
[/quote]

While you make an interesting point about 'free' memory within the allocated heap size, texture memory actually resides outside the JVM entirely (and isn't garbage-collected, etc.) So even if I did have 250MB of textures (In practice, I would have much, much less), this wouldn't buy any 'free' heap space to use for other purposes. (Although, more fortunately, this also means it doesn't force memory usage much larger than the textures themselves, either)
0

Share this post


Link to post
Share on other sites
The sneaky secret of efficiency, for both time and space concerns, is that it does not always increase in a sensible relationship to code complexity. In other words, sometimes you have to write more code to use less memory (or do something faster). This sounds like one of those cases. At some point you have to decide which tradeoff to make: accept simpler code with higher memory consumption, or accept more complex code to get the lower memory usage. Depends on your priorities.
0

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1314831681' post='4856051']
At some point you have to decide which tradeoff to make: accept simpler code with higher memory consumption, or accept more complex code to get the lower memory usage. Depends on your priorities.
[/quote]

Reasonable enough, really. So much of development is about making tradeoffs, anyway: performance vs. flexibility, and so forth. In the end, saving a couple hundred KB probably isn't worth the additional code complexity of encapsulating property groups, checking a half-dozen things for null references each frame, and creating/destroying property classes as effects become active or inactive. Even when this extra memory is almost entirely a result of overhead known to be unnecessary ahead of time in the general case. It may simply be the cost of avoiding something potentially worse.

I had hoped there might be some obvious alternate way to go about this, but if not... Nearly all the source code I've perused to examine their rendering systems either had sprites that were much less flexible and capable in the first place, or legitimately needed most of their extended properties for the majority of their sprites. But it's probably better to err on the side of flexibility and clarity than worry about memory that is probably largely an ideological concern at this point.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0