OK, our mod, the Project6014 is well in the point when we should have the .exes and .apps ready.

I ran into a problem trying to make a runnable OSX .app that would work on other peoples' computers.

The problem is that only SDL_image is added as complete framework inside the app. From the others, only a single header file is added, like SDL.h, Ogg.h and vorbisfile.h.

How can I make the rest appear inside the .app as complete frameworks too?

Java's print syntax is not unnecessarily long-winded. Flexibility and clarity come at a reasonable cost in length.

Well put! There's always pros and cons in every design choice and that's why no language can be claimed to be absolutely better than another one. For certain tasks and purposes, yes, one trumps the other, but not for every one of them.

What I meant to convey with my "unnecessarily" was that from learning-your-first programming-language point of view, it might be confusing to face a wide array of flexibility and options, when all you need for your specifc purposes is just one of them.

In that infamous basics of programming class we only used System.out.println for that one purpose -printing lines on screen-, and received quite a little in the way of explaining what is this System, why does the command come only after all those prefixes, or how it could be declared shorter as you showed in your example.

Now that I think of it, that's more a fault of the teaching being bad than the language being unwieldy.
I think the teacher tried to achieve both: a) Show us students the versatility of java by demonstrating long-winded commands b) make it easy to learn by not painstakingly explaining all the details of the command, just using one instance of it in practice to see what happens.

Unfortunately, from my POV he failed in both accounts:
Typing in long commands without seeing the point in the syntax just made it frustrating for a beginning programmer. This made me veer towards languages that seemed more "sensible" to me at the time.

I have to agree with onpon4 and Novus: Python is an excellent language for its clean, intuitive syntax and ease of use (especially when learning it as your first programming language): For example you don't have to muck around so much with different variable types as in C/C++ and it's more straightforward to manipulate files and use system command line commands. Java puts me off with its unnecessarily long-winded syntax (the likes of system.out.println vs Python's print).

I've been programming stuff for network simulators for a living a while now. My main tools have been both straight C and C++. I think those are still the "bread and butter" of programming languages in the engineering world. They tried to introduce Java in place of C in the introduction classes here in the university's computer engineering studies some years back , but have since quietly returned to teaching C.

In addition Python has been a lot of use for me when programming scripts for extracting results from tens of thousands of files. That could've been done also in C/C++, but would have been a more tardy way, with all the compilations and the quirkier format for file manipulation.

I've found
www.cplusplus.com/doc/tutorial/
useful at learning new things and rehearsing the old.

Even though it's for C++, the first parts of the tutorial (Basics of C++, Introduction, Control Structures, Compound Data Types) hold true for C since these parts are essentially the same for both languages.

The best way to learn how UQM works is to read and re-read the source files like crazy
It also helps a lot, if you have finished the game hundreds of times and played it a gazillion times. It works wonders on understanding what the functions in the source code really do.

Also, always, if you modify something in the code, add a comment with your own unique identifier at the end of the line like // ZXZ. It will save you a lot of time hunting down what you've done, especially if you leave the code alone for a couple of weeks and return to it after that. When the mod keeps growing it's not a bad idea to make a list of files that you've tinkered with and add a short summary of mods you've done to that file.

Hey, that's cool!

Thanks. Now I can finally sleep.

OK, here's a Question of utmost importance!

Why is the main ship, the Precursor vessel a.k.a. tug labeled sis_ship everywhere in the source code, I mean... Where does it come from?
SIS. Ship Is Ship? Super Intelligent Ship.? Symbian Installation System?? Swedish Institute for Standards?

Yarr, it's driving me nuts!

YEAAH!

The ArmBrake was cleverly disguised, but after rigorous search, I found it hiding cowardly in sis_ship.c and dealt it swift justice.
The overflowing integers were SIZES dx, dy, udx and udy in the preprocessing function.

It just happened so, that with the upgraded speed to match the 640x480 resolution, the main ship's max speed with all thrusters was 32768.
Now, too bad, SIZE is a signed 16-bit word, so the max value it can hold is 32767.

Thus 32768 was wrapped around to -32768 creating an ugly bounce when decelerating.  This only happened when letting go of thrust instead of instantly hitting the top speed since the faulty part of the code was only ran when the state of control buttons changed, I guess.

      ORIGINAL:
         udx = dx << 4;
         udy = dy << 4;

      MODDED:
         dtempx = (SDWORD)dx;
         dtempy = (SDWORD)dy;
         if((dtempx << 4) > 32767)
            udx = 32767;
         else
            udx = dtempx;
         if((dtempy << 4) > 32767)
            udy = 32767;
         else
            udy = dtempy;

geeky fun 

YES! That's it!

I should've considered using the infamous ArmBrake variable months ago...

Yep, I doubled them both.

Ship works OK in 320 x 240, but does that bouncy stop in 640 x 480. 

Ah, I partied too early...

Flying in hyperspace still has some quirks:
When I go right or down at full speed and release thrust, the ship doesn't slow down nicely, but bounces backwards before stopping, as if punched back by a giant fist :-p.

Going up or left at full blast everything is OK.
Maybe some int if overflowing somewhere afterall?

Yep, I had a meek hope that I would achieve the effect of multiplying by two by just changing one of the WORLD_TO_VELOCITY thingies since when I changed both, it did basically nothing.

But as Angelfish suggested, doubling the flagship speed did the trick nicely in hyperspace and seems to work for other races as well! So that's the direction I'm taking.

Ship speeds in melee might be more problematic though since the ship speed stats are initialized in ship structs with constant numbers.
Variables cannot be used for initializing so I must cram that *resolution_factor somewhere else than in those structures.

The ship starts moving quite sluggishly, then suddenly zaps into an incredible hyperspeed, moves sideways and finally disappears from the screen!

Yes, just doubling the speeds would be a clear-cut way of doing the thing. It wouldn't be too hard to introduce the *2 factor to every ship.
It's just that I'm becoming the kind of coding elitist who's always looking for the most elegant way of doing things

Making the graphics is time-consuming, but has been easy enough once I found an OK batch resizer for OSX and also realized that I can reuse the existing graphics to a large extent. That way I only have to make the largest scale graphics anew.

It's only the melee graphics that pose a problem: I'm not sure if I know how to make that lighting/shading thing look as cool as in the original graphics.

Hi!

I've been able to get the "real 640x480" project going pretty nicely: I've got the interplanetary graphics all updated now plus the melee icons, border and interface drawing etc.

In most places it's been easy enough to multiply the defined constants that have something to do with graphics with 2 so that they correspond to the doubled resolution.

I ran into a vexing problem with the ship velocities though. Now that the resolution is doubled, the ships move at half their original speed at hyperspace. (Also melee, but I'm not going there yet). I tried to introduce the resolution factor to the WORLD_TO_VELOCITY and VELOCITY_TO_WORLD defines in velocity.h.

They were basically
WORLD_TO_VELOCITY (s) = s<<5
VELOCITY_TO_WORLD (s) = s>>5

Trying either
WORLD_TO_VELOCITY (s) = s<<(5+1)
or
VELOCITY_TO_WORLD (s) = s>>(5-1)
(the same as multiplying by 2 basically...)
did double the ship speed in interplanetary but kind of messed up the ship handling there and totally wrecked the ship behavior in hyperspace so I think this is not the way to do it here.

I could multiply by 2 many things in the functions in velocity.c, but if you can think of a more elegant way, please let me know.

If you guys are willing to stretch the original 320x240 to doublesize that'd be great!
Then the graphics could be incrementally enhanced, replacing the stretched gfx with completely new art slowly but surely, one at a time.

One thing to bear in mind:
There are several different algorithms for resizing. The one to be used should be a resizer that retains sharp edges i.e. doesn't blur.
That'd keep the original look of the graphics.
Whereas i.e. bicubic interpolation does make things smoother, it makes them also... blurry.

 I for my part rather look at a bit blocky and pixelated art, than plasticky blurred gfx that still clearly show that they're modified lo-res graphics.

I'll second that. The demo will be 320x240.
Whilst it's been interesting to toy around with the better rez, the amount of PNGs that would need resizing is insane.

There are batch resizing programs I've used that can resize hundreds of images in a matter of moments, but even with those there would be some kinks:
- All the resized files should be put into separate addon folder and then write correct resource mappings for all of them, if we want to keep the old gfx available for other resolutions
- Writing new .ani files that contain correct  centering information for the new, larger frames
- Comm screen animations' c source code would need a lot of work to align the anim frames correctly
- And of course eventually: Actually drawing new, more detailed image frames, not just using the old 320x240 resized to 640x480