Had a feeling Z was involved haha. Also its worth mentioning here that I am NOT using the normal math sin/cos/atan2 functions, as they deal with floats which are slower. Im using custom routines. As of now, sin/cos are using lookup tables and generate a char that is the fpart, which gets added to your location, which is a signed int, formatted 1 byte sector, 1 byte coordinate, and 1 byte fpart. If I need more map space, I can use a long and make the coordinate 2 bytes.

For the arctan, I might end up doing something like char angle_decimal = non_x_vector * 256 / x_vector, (which should give me the decimal, mapped to a byte), then locating angle_decimal in the sinLUT to get the angle.

Edit: One of the caveats being encountered is the domain of arctan. While cos/sin have a domain of [0, 2pi], arctan goes from [-∞, ∞]. How can I deal with this?

Edit 2: Anyone skilled with spritework want to draw a sprite of the Narada from Star Trek 2009?
UPDATE --- 0.51 alpha

The newest, and first VFX tidbit added is the Warp Speed animation. This animation appears when your ship's speed goes above 10 fields/tick and increases in intensity for every 4 units of speed. This means that the effect will be more intense when traveling at Warp 9, for instance, than at Warp 3. There is also a light blue circle in the center of the effect that increases in radius as your speed increases. Funnily enough, I aimed for semi-realism in that regard... as when traveling FTL, the cosmic microwave background radiation would blue-shift into visibility and warp towards the front of your ship.

Anyway, aside from that tidbit, damage to your warp DRIVE now results in your maximum warp speed being diminished, culminating in your ship being dropped out of warp entirely once your warp drive hits 0% health. While the drive remains at 0%, attempting to re-engage warp speed will fail.

Finally, I now need some advice. It is my intent to place tech item data into an appvar, and sprite data into a separate appvar. These appvars will be on the calculator for now, but will eventually be saved server side, and your calculator will be sent only what is relevant to it. This means I need to generate data-only appvars with (1) sprite data, and (2) tech info. I can technically use the PHP library that I used for Blast AV to generate the tech info one, but for sprite data, can convpng export sprite data to an appvar?
Great work!

As for convpng, I do believe it can output to an appvar. Seeing as this is a C program, I believe you have to compile it differently, perhaps as ICE in order for it to work. You could also look at the ICE HD Picture thread, you may find you answer there. However, I think it can be done.
Alright, so I just added support for phasers, and began adding the torpedo system, and doing so added a weird glitch. Let me explain what happened, and I'll post the link to the github here, because I've tried a ton of things and it doesn't seem to be helping.

I added to main.c, lines 259 - 275, and made a few other requisite changes to support phaser firing, such as adding k_2nd to the keys_prior array and enum. Running the program again, it behaved normally, until I attempted to fire the phasers. Holding the phasers key for any length of time causes corruption on the lower screen icons. Eventually, it crashes. I had already deduced that the activeweap pointer was being screwed with somehow, and it was confirmed when Cemu told me crash was due to null pointer deref.

To test further, i proceeded to add weapons to the tactical screen. The point of this being, the tactical screen will show you which weapons module you have currently activated. This defaults to phasers. If neither module appears active, this means that something is wrong with the activeweap pointer. As I suspected, neither module was active when I viewed Tactical.

I then removed modtype from the module structure definition. While I knew this wasn't part of the fix, I realized I dont actually use or need that and it was complicating my code. I can simply use techtype to distinguish between module types. Making these revisions actually appeared to fix the activeweap issue, but only for a time. It started to allow me to shoot, but then warpcore and shields weren't pointing to the correct place (because i moved all the techtype enums up by 1). After fixing this, I began noticing that the speed indicator was glitchy, and both weapons on Tactical were inactive, meaning that now, both the activeweap and warpdrive pointers are broken. I then added the following lines of code to the program, line 200:

 if(activeweap != init_SetPointer(&ShipModules, tt_phaser, 0) || warpdrive != init_SetPointer(&ShipModules, tt_warpdrive, 0)) {
            player->deathreason = 3;

To trigger a catch and exit for those two pointers. The program immediately exits when it hits this block.
Adding the exact same block a few lines up, line 167 (just after the pointers are set), does NOT exit the program. I've pored the code over and over and have no idea why it's behaving like this, so I'm posting the code hoping maybe someone else might find whatever is wrong.


Edit: Fixed the warp drive issue, but the activeweap issue persists.
Edit 2: Added the (!player->tick) conditional to mean that the program will only exit if the pointer is destroyed within the first tick. This time, the program did NOT exit, meaning the pointer is destroyed after this block of code runs once but before it runs a second time.
UPDATE -- v0.54 alpha

Fixed above detailed bug. Got it in my mind to copy the above if(activeweap...) code to the very end of the loop (right above the tick increment) and keep moving it up. Eventually I found a place where it stopped quitting and actually didn't quit. Meaning the bug was located between those two locations. Traced the bug to one of the two power cycle functions, and found it within the first. I had resized the ShipModules array down by 5 slots and didn't change the number of power cycles to match, causing an overflow, and possible corruption of other statically-allocated memory. This issue has been fixed. Screenshot below demonstrates (1) the tactical screen, (2) toggling between phasers and torpedoes, (3) firing phasers, and the difference in power use between a quick shot and a charged shot (and firing a shot at >100% power), and (4) the fact that the warp core now VERY slowly regenerates power over time.

UPDATE -- v 0.57 alpha

A number of performance enhancements, bug fixes, and tweaks. I have noticed that total power loss occurs too rapidly, and starts lower on the module list and works its way up. Have been brainstorming ways to prevent this, and make power loss slower and more realistic. Eventually stumbled upon a solution, called "power spend down".

As you may know, in my game, the warp core's power output is not a gradual decline, it's a step-down decline. Your core produces 100% power until its health hits 74%, then it produces 75% power until it hits 49% health and so on. Once the warp core's power output drops to 50% (at ~50% health), each system begins to draw less power than it normally does (rather than formerly continuing to draw it's normal power, then leave the last system on the list unpowered). This distributes the power loss evenly across the board. This does NOT affect right column power settings, which will continue to work the same. This causes every module that constantly draws power to begin to lose power at a steady, but slow rate, giving you enough time to address the situation. It also causes modules that draw power when in use, like weapons, impulse, and warp drive, to regain their energy at a slower rate.

The converse is also true. When your warp core is healthy and your ship is producing enough power, and ONLY when your modules are set to use 100% power, each module will actually draw 20% more than it normally does, until the module's reserve recharges. This eliminates the need for you to switch systems offline to let them charge back up... they'll slowly do so on their own. The warp core now officially gains back power 4x slower than your other systems, regardless of its state.

It is my hope that these features help battles last longer. :p
Still working on the rendering engine, and moving entities/projectiles within the map. After that I'll publish a demo.
Update -- v 0.60 alpha

Splash screen/main menu added
Fatal error resolved where ejecting the warp core would crash the game due to destruction of pointer subsequently used. Short term solution: test value of pointer. Long term solution: retain pointer, alter module "type".
Significant increase in file size.
Star Trek logo icon saved to appvar "trekvfx". Without this present, GUI should render everything except the logo.
I also created an online document/reference with a print friendly css template. This guide is located at: http://clrhome.org/startrek/guide/
Update -- 0.63 alpha

Navigational Display added. Renders on top of everything else, including warp effect.
Targeting Display added. 40˚ angle of targeting available within the viewscreen.
Targeting display shows charge state in GUI (red circle expands to fill inner circle. Phaser fully charged when inner circle red.
Open to suggestions for improvement.
** I am now opening the thread to optimizations as well. Anyone who can figure a way to optimize any of the code you see, feel free to post in the thread.
** 0.61 bug with rotation display persists

** This version either revealed or introduced a bug. Attempting to change your rotation does not work. Attempting to change your pitch, either way, changes your pitch to 255 and your rotation to 250. This is weird. After that, pressing the pitch (up/down arrows) the opposite direction change the pitch to 0 and the rotation to 3. After that, pressing either rotation key (left/right) resets it to 0. This is literally the only response i get from the pitch/rotation keys... at least on screen.
I've pasted the code link here: https://github.com/acagliano/startrek-ce
You overwrite the angles variable when you do:

pos->vectors[2] = byteSin(yangle);
MateoConLechuga wrote:
You overwrite the angles variable when you do:

pos->vectors[2] = byteSin(yangle);

Thanks for that. Honestly that's something I should've seen.

At any rate, now that that bug is fixed, the viewscreen overlays are done. Now it's time to wrap up the entity movement/collision and rendering engines.

Update -- 0.67 alpha

Updated much of the GUI.
Widened the viewscreen
Display of information in Tactical uses icons, not strings.
Speed indicator now has warp and impulse icons.
Update --- 0.70 alpha

-- Sensors GUI added. Ship icon positioned at center of sensor screen, radar line rotates the screen.
-- All other objects for now are red dots.
-- Sensor seems to function properly, but revealed glitches in the movement system.

I downloaded the latest release off of Github, but when I run it it says 'trekvfx apvar missing'. Where should I find this? Thanks!
Looks like it is in this folder: https://github.com/acagliano/startrek-ce/tree/master/src/gfx
Thanks a lot for the quick reply! I never would have found it there! Smile
Legoman314 wrote:
I downloaded the latest release off of Github, but when I run it it says 'trekvfx apvar missing'. Where should I find this? Thanks!

For future reference, I reference external graphics appvars as "assets files".
Convpng exports assets files to src/gfx, so that's where they will be in the source code.
As of now, there are two assets files.

The first is trekicons.8xv. This file is optional. The game will function without it, but will not have many of the GUI elements, like icons for shield/hull damage, the ship status indicator, and more.

The second is trekvfx.8xp. This file is essential, and its absence stops the game from running. This file contains the game's sprites... currently this is: the targeting GUI, the phaser sprite, the torpedo sprites. I have 3 more sprites left to go. There will eventually be a third appvar, trekstats.8xp. This will store, temporarily, information on tech and weapons that you can equip. This file will also be mandatory.

When the game goes multiplayer, trekstats.8xp will be removed and will be something on the server that you can download, look at, and use. The general weapon/tech sprites and icons will probably stay calculator side, with the ship sprites being downloaded.

Apologies for the lack of documentation on where those were. Also, for anyone wishing to play around with the GUI, here's some documentation: http://clrhome.org/startrek/guide/ . Not everything written down is implemented yet though, so...
Update -- 0.72 alpha

Rendering officially implemented and functional, albeit glitchy, although I do not think that the glitching is actually in rendering itself, but more, in the trig my coordinate/movement system uses. I took a screenshot of the rendering in action. At some point, you see things working as they should. A phaser is fired, it appears, scales down as it moves away, and eventually vanishes beyond the render distance, then is eventually removed from the map.

It's great when the phaser shoots straight as intended, but as you can see, at some rotations the phaser shoots... at a completely weird direction. Seems I have a bit of fixing to do... but we're getting there. Still have yet to handle sprite rotation based on relative angles, and making weapons look like they're being shot from your ship, not being teleported in front of you.

Code pushed at: https://github.com/acagliano/startrek-ce . for anyone who is better at 3d trig than me.

Also, what colors should I make the dots on sensors?
Color for enemy ships? Allied ships?
Color for weapons fire? Should that even show up on sensors?
Color for terrain? Stars, planets, black holes, etc?
Great Work!

Here is the color scheme I think it should have:
Allied Ships: Blue
Enemy Ships: Red
Terrain: Green
Black Hole: Orange Icon of Black Hole
Stars: Yellow
Weapons Fire: Only Ballistics, show up as red icon
Thanks! I'll log this.

Now, in the interest of perhaps trying to debug my trig/coordinate issues, let me post my cosine lookup table, and the code I use to calculate the trig values. Anyone see anything causing the code to have very weird effects? You can be moving +x, +y at one angle, then like 2 degrees over be suddenly moving in the opposite direction.

const char cosLUT[64] = {127, 126, 126, 126, 126, 125, 125, 124, 123, 123, 122, 121, 120, 119, 118, 117, 116, 114, 113, 111, 110, 108, 107, 105, 103, 101, 99, 97, 95, 93, 91, 89, 87, 84, 82, 80, 77, 75, 72, 70, 67, 64, 62, 59, 56, 53, 50, 48, 45, 42, 39, 36, 33, 30, 27, 24, 21, 17, 14, 11, 8, 5, 2, 0};
// these values represent the fpart of the translation of your ship's position per cycle. The value is treated as N/127, where N is a value from this table.

signed char byteCos(unsigned char x){
    if(x < 64) return cosLUT[x];    // for values 0-63, fetch value from table
    else if(x < 128) return -cosLUT[127 - x];   // for values 64-127, subtract from 127, fetch and negate
    else if(x < 192) return -cosLUT[x - 128];   // for values 128-191, subtract 128, fetch and negate
    else if(x < 256) return cosLUT[255 - x];   // for values 192-255, subtract from 255, fetch.
// i know there's ways to optimize this better, but while my trig is broken, I want something easier to read.

signed char byteSin(unsigned char x){
    return byteCos(x-64);   // subtracts 64 (90˚) from value, then calls cosine.
byte angles in the program are 256-degree circles, with each byte degree mapping to approximately 255 * N / 360 actual degrees.
Update -- 0.73 alpha

Trig issue fixed. All weapons fire properly for all directions except for 90˚ and 270˚.
**Wild swinging of a dot on the map as you approach it means the object is above or below you.
Remaining Bugs/Things to Do:
-- Rendering still broken
-- Handle collision (interpolate any point on line between two points being within a certain distance of (target) object).
-- Design Narada, shield impact, and ship impact sprites.

Attempted to make my own arctan routine, however it's always returning 0. Any idea why?


const int arctanLUT[18] = {0, 11, 22, 34, 46, 59, 73, 88, 106, 126, 151, 181, 219, 272, 348, 473, 720, 1451};
char byteATan(long non_x, long x){
    char index = 17, quadrant;
    int value;
    if(x == 0){     // handle infinity
        if(non_x > 0) return 18;    // 90 degrees
        if(non_x < 0) return 54;    // 270 degrees
    value = abs(non_x / x);
    if(non_x > 0 && x > 0) quadrant = 0;
    else if(non_x < 0 && x > 0) quadrant = 1;
    else if(non_x < 0 && x < 0) quadrant = 2;
    else quadrant = 3;
    while(index >= 0){
        if(value >= arctanLUT[index]) return 18 * quadrant + index;
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
» View previous topic :: View next topic  
Page 4 of 10
» All times are GMT - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum