next »

[JobLeonard]

It's probably the lack of dedicated graphics card and the Intel chip just isn't enough.

That's... I'm sorry, what? What kind of fancy features does your engine use?

[JDance]

Please finish the game instead of optimizing it for old laptops

[kleiba]

Here we are, in 2013, struggling to run a turn-based game that only uses four colors... ;-)

[Eigen]

There's certainly room for optimizations. It's nothing complicated but there are quite a few passes (or layers of stuff), some of which requires a lot of texture switches and I remember seeing something about that on the SFML forums saying that it can be costly and batching should be preferred. Basically each tree is a separate texture and it'd make sense to batch those into one but they are separate objects as well, so working around that would be a complete hack. I don't have a tree layer, but at one step there's a depth sorted list of objects to render this frame, some of which are trees. Those objects are in random order each switching the current texture which is probably the issue.

Plus there's the GUI code (and text rendering w/ glyhp lookup in my custom font impl.), which may not be the fastest and which is rendered on each frame. I guess agressively caching everyhing would be a solution since there's plenty of RAM to go around, but I need to do some calculations first.

Anyway, without first seeing and experiencing where the bottlenecks exactly are I can't and won't do anything. And the fact that the game is turn based has nothing to with the thing, I think

It might just as well be that a correct set of drivers fixes the issue.

[JDance]

Some basic optimizations will probably make the game more efficient, but as a solo dev theres always too much to do. A focus on creating instead of optimizing creates more and better games. Optimizing can be done later, or just not at all since it works well on modern computers

[jO]

Some basic optimizations will probably make the game more efficient, but as a solo dev theres always too much to do. A focus on creating instead of optimizing creates more and better games. Optimizing can be done later, or just not at all since it works well on modern computers

Could not agree more.
Finish the game, then fix it.

[happymonster]

As a fallback you could draw everything in software to a texture and then blit it to the screen with a suitable scale factor. As the screen texture is small this might help, but not sure if all the work would be worth it..

[JobLeonard]

A focus on creating instead of optimizing creates more and better games.

I agree with the "more" part, but you have a funny definition of "better".

[JDance]

A focus on creating instead of optimizing creates more and better games.

I agree with the "more" part, but you have a funny definition of "better".

The definition in this particular case would be something like "more content, better gameplay, etc is better then getting it to run well on old laptops". Just my opinion that

[eigenbom]

I agree with these chaps. Do not optimise for lower end machines! Make your first 10000 sales and then think about it.

In the meantime you could provide a "low-spec version" by allowing the player to disable all visual effects, extraneous layers, etc.

[JobLeonard]

From what Eigen has posted, I think this points to a deeper problem with the way sprites are handled, which may or may not be the partially the fault of the framework.

And I disagree with the advice here - it's overly simplistic. Premature optimisation is one thing, but if the issue is essentially flawed software architecture, then the longer you wait, the bigger the rewrite required because it will be deeper ingrained in the system. Basically, think about what kind of technical debt you incur upon yourself by letting this be as it is now.

What if you want to make this game cross-platform? As is, this probably won't run smoothly on phones, and even if it does, it will be a much bigger drain on the battery than it needs to be (optimise for fan noise).

I have a friend who got featured on Google Play with a simple but fun game:

Also, interesting things happened to the ratings, for both paid and free versions. They started out near 5 stars, but dropped almost linearly over time to around 3.6 stars. According to several 1-star reviews, there were two causes for this:

•    Some mysterious problem with certificates, that I couldn’t reproduce on any of my devices. Apparently it prevented installation for a subset of users. I released a new version yesterday that was signed from the command line using jarsigner from JDK 6 instead of JDK 7 that Eclipse might have used, but I’m not sure if that fixed it.
•    Random freezes due to bugs in libgdx’s EarClippingTriangulator class. I believe I fixed those with this pull request and released a new version of Patchy that incorporates this code.

Because I was travelling, both fixes came too late to make any difference to the app ratings during featuring. Oh well.

You want these fixes to happen before releasing the game.

[JDance]

Well it's all valid points, in the end it's a matter of priorities

[Eigen]

As a fallback you could draw everything in software to a texture and then blit it to the screen with a suitable scale factor. As the screen texture is small this might help, but not sure if all the work would be worth it..

I might do a little test application just for science. Draw X different sprites consecutively in HW, w/ SF blitting and HW/merged sprites with sub-rects.

I agree that premature optimization is bad in most cases. I'm definitely going to go over the code and structure to clean it up (hopefully resulting in faster execution) but not at this point because I'm surely going to be changing stuff anyway since nothing is freezed yet. I'd rather start from a solid piece of code rather than something that might be temporary.

I understand the overall enjoyment is a sum of all parts - gameplay, graphics, sounds and how well and smooth it runs but on majority of systems it should have no problems. In makerimages' case, as I said, it might as well be a driver issue because only recently have Intel's drivers become any good. I'm not sure how external problems like that are usually handled but I don't see much I could do.

Makerimages, do other games run well on your system? Eg. does Doom 3 run on it? My previous laptop with the weakest graphics chip could barely run Doom 3 but Pioneers ran well, even in highest resolution with lots of tiles to render. Sadly I don't remember what CPU it had ... I would boot it up but the power cable has snapped.


Anyway. Not much progress lately. I was busy with my text-based RTS and a little 3d game more recently. I've just been doing some localization fixes and changing certain UI elements to accomodate longer texts. A dude is translating it to Russian, which might bring a whole new audience and that's great. On Twitter someone even mentioned it should be in Japanese, but I doubt it would work. A lot of UI is designed around quite small characters and I'm very doubtful you can fit Japanse syllables in there.

[makerimages]

Toss away the optimization, fuuu found me some new driver somewhere on intels site that made Pioneers run PERFECT! Translating into Estonian aswell!

[vlaube]

I've just been doing some localization fixes [...]

My body still ached but I felt full of energy and something called me for the uknown.

Just found this while translating, not sure if you fixed it already,

[JobLeonard]

Yes, that's a k too many

[TeeGee]

The Mac version crashes whenever I try to run it with a generic error message that it may not work on my version of the system (10.6. or that I should download it again. The last version worked just fine.

[Eigen]

Yeah, 10.6 is problematic. Firstly, I don't have access to such a machine for testing and secondly we've been starting to use C++11 features for which the compiler requires 10.7 minimum target. I could probably work around that with ifdefs on OS X but differentiating code like that ... it's probably going to kick my ass along the way. Another option is to drop C++11 since its use is (currently) minimal but I dunno, it's pretty nifty (lambdas, brace-enclosed initializer lists, better pseudo-random number gen. with distribution, etc.)..

Are you not upgrading due to incompatible hardware?


edit: I might be able to try and build something with 10.6 minimum this week if you don't mind helping test it?

[TeeGee]

Sure, I'll gladly test it.

I'm not upgrading for pretty superfluous reasons: lack of important changes, lazyness + I still play some older games that rely on Rosetta.

[Eigen]

Finished up drag'n'drop today.



You can now add certain items to quick slots and access them with numeric keys 1-5. Makes life easier especially when you quickly want to use the axe or something. Next I'll add dragging between campsite/ship and character inventories.

And the OS X build now runs on 10.6 as well. I rewrote the C++11 bits for now until I figure out what to do with it.