Hi,

I've been working on Elite4k, a trade and space sim, since December. The game is basically a clone of evergreens like Elite and Privateer: You fly your spaceship from planet to planet, trade goods, buy upgrades, hunt pirates, mine asteroids or turn pirate yourself ... I think you all get the picture I've almost finished the game now, with a size of around 4.8k and enough optimization potential remaining  (hopefuly  ) to reach 4k. However, some issues turned up during development which keep bothering me. I would be grateful for any input on the following questions:

Text rendering I'm currently using drawBytes to draw text from a resource byte array to a graphics context without string overhead. Is there a smarter way to do this? 

Number rendering I'm currently using a method which fills a byte array from a given number by setting the current modulo-10-value of the numeric value to the current byte, then decimal shifting the number and advancing the output byte. Is there a smarter way to do this? Perhaps some light-weight number format method in the API I don't know about?

Matrix inversion For the 3D space sim, the inverse camera matrix is required. Two ways to get it: Matrix inversion (my unrolled version is 12 lines with lots of multiplies and adds) or premultiplication with the negated matrix components. Which way to go? Premultiplication eliminates the inversion code but requires some control flow in the geometry pipeline. Any experiences?

Loading and Saving For a game where you can easily spend dozens of hours, a load and save game function is a must. The amount of game data I have to load and save is around 20 bytes. One option is to write out a text representation of the values and let the user note it down and reenter it to load a game (old-skool console style). However, 20 bytes mapped to easily typable characters is a lot of text. So I consider using the clipboard: Copy to get the current game state as a string, paste the string (which you saved in some file) to resume. Does this make sense? I'm a bit in doubt

Array Access When accessing array cells in approximately linear (depending on control flow) sequences, is it better to have something like "data[basepointer+1] (...) data[basepointer+2] (...)  data[basepointer+27] (...)" or is it better to go unary where possible "data[pointer++] (...) data[pointer++] (...)"?

Thanks for your input

Wolfgang

"I'm a ****ing starship, I'm allowed to cheat!"
GCU Arbitrary, Culture Craft




 

Loading and saving: using base 64, 20 bytes is 27 characters. That's not much longer than the passwords in some games I've played, and it's a bit more intuitive for a non-technical user than putting stuff in the system clipboard.

Array access: data[pointer++] repeated 27 times will compress a lot better than data[pointer + 1]...

This is what I found:
Clipboard: Toolkit.getDefaultToolkit().getSystemClipboard().setContents(new StringSelection(""), null);   ==> adds 150 bytes
Dialog: JOptionPane.showInputDialog(this, null, "");  ==> adds 61 bytes

Or even smaller if you just draw it to the screen, since OP is already using methods to draw text to the screen.

Thanks for the input on the issue! Fortunately, neither the input nor the rendering of the save-game-string is the problem, I'll probably end up well below the mentioned byte counts by integrating it into the existing event logic.

From the responses so far, I conclude that a save-game-string of, say, 30, alphanumeric chars wouldnt be a problem (correct if wrong).

Thanks

Wolfgang

Without spending any time actually testing things, one probable-optimisation which jumps at me is moving the "Write zero" up before the "Write values" and skipping the test. I.e. replace
with

That saves a few bytes in the uncompressed version.

note - pjt33 replied while I was typing, so there maybe some duplication

Only 2 optimisations I can see missing are to use the ternary operator & include the final if statement inside the loop.
Both of these eliminate the duplicate array access instructions, which are rather large.
Together. i'd guestimate around 10 byte saving?

Forgive the tampering with your literals - embedding non-trivial literals is one of my pet hates  



:edit:

Further optimised by combining the 2 ternary expressions inside the loop into a single or'ed one.

Correct, and exiting early reintroduces the if. Stupid me. Thats what you get for debugging a geometry pipeline while playing solitaire with your wife and posting in boards simultaneously 

Anyhow, your optimizations have put an end to that discussion, very very nice!

Thanks

Wolfgang

PS: "Whoever finds embedded literals may keep them" 

Doh! There's an else clause.

Of course, if we can change the requirements we could have it pad with 0s rather than spaces for simpler, shorter code with a retro feel...

Anyhow, your solution raises an issue I've been thinking about a lot: API calls versus do-it-yourself. As I see it, there are three basic cases. Two are no-brainers:

Never ever use the API, as in max/min or event handling, where the API calls compress much worse than your own constructs.
Always use the API, as in drawing ovals or filling polys, where your own constructs get much too long.

But the third is tricky: To use System.arrayCopy() or Arrays.fill(), or not? My guess is that for using such methods once, your have to pay the full overhead, but by using them frequently, the overhead should decrease ... where is the breakeven, when your own constructs start to get more expensive than the call overhead? I'm aware that this is almost a philosophical question and depends on the type of method we are talking about.

Of course, my general statement does not hold if the drawing functionality is a central part of your app and involves complex stuff hard to do using the API. In Ares, I referenced the backbuffer as a byte array and implemented the fake-phong rasterizer based on that.

On the other hand: setRenderingHints, setComposite and drawOval is worse than a hand-rolled antialiasing bresenham? Obviously, I don't know any details ...

I hadn't come across setComposite before, so thanks for that. It doesn't do everything I need for Grav4k, but I may well find it useful in the future.

I'm doing fillOval , which is simpler than drawOval. I'm also, as Abuse suggested, sacrificing some speed for simplicity.

A bit Off-topic,

    I found today Elite Plus for DOS boxed for $6.00. It's on two 5 1/4 floppies!! But 150 pages manual its pure game design gold.