|
Pages: [1]
|
 |
|
Author
|
Topic: Velocity problems with hi-res experiment (Read 2128 times)
|
superbutcherx
*Many bubbles*
 Offline
Posts: 116
|
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.
|
|
|
|
|
Logged
|
|
|
|
Angelfish
Enlightened
Offline
Posts: 568
|
I don't really know how to help you since I'm not that familiar with the UQM source, but it's good to see that you've made progress  .
One question: How exactly is the ship behaviour wrecked? Is the ship too fast, too sluggish or just not manoeverable?
It seems that you're creating a universe double the size, in pixels, so wouldn't it be better to just increase the ship's max speed and accelleration stats by 2?
|
|
|
|
« Last Edit: May 18, 2010, 09:45:15 am by Angelfish »
|
Logged
|
|
|
|
superbutcherx
*Many bubbles*
Offline
Posts: 116
|
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.
|
|
|
|
|
Logged
|
|
|
|
Angelfish
Enlightened
Offline
Posts: 568
|
For the melee graphics you could just use the timewarp graphics. As to the most elegant way of solving this, I don't know, but the way the ship behaves I think you've got something terribly wrong .
|
|
|
|
|
Logged
|
|
|
|
|
|
superbutcherx
*Many bubbles*
Offline
Posts: 116
|
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.
|
|
|
|
|
Logged
|
|
|
|
superbutcherx
*Many bubbles*
Offline
Posts: 116
|
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?
|
|
|
|
|
Logged
|
|
|
|
Angelfish
Enlightened
Offline
Posts: 568
|
Did you double both the max speed and accelleration as I suggested?
|
|
|
|
|
Logged
|
|
|
|
superbutcherx
*Many bubbles*
Offline
Posts: 116
|
Yep, I doubled them both.
Ship works OK in 320 x 240, but does that bouncy stop in 640 x 480. 
|
|
|
|
|
Logged
|
|
|
|
Alvarin
Enlightened
Offline
Gender: 
Posts: 799
|
You might want to change option "ArmBrake=1" to "ArmBrake=0"
Good luck!
|
|
|
|
|
Logged
|
|
|
|
|
|
superbutcherx
*Many bubbles*
Offline
Posts: 116
|
YES! That's it! 
I should've considered using the infamous ArmBrake variable months ago...
|
|
|
|
|
Logged
|
|
|
|
Angelfish
Enlightened
Offline
Posts: 568
|
omg what's the armbrake 
|
|
|
|
|
Logged
|
|
|
|
superbutcherx
*Many bubbles*
Offline
Posts: 116
|
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
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1]
|
|
|
|
|
