Try this for putting the object in view of the player, Rotation is output

Code:

Hope this helps!

What is "global"? Would global be defined as the default rotation, (0 deg by 0 deg), where the ObjectRotOffset would be defined as the deviation from that? Also, wouldn't there only be 2 rotational vectors, one for the X and Y and one for the Z?

Also, on a related note, how does Star Trek describe rotational data? Like I've heard quotes like "turn to 137.5 degrees, mark 5" or I've heard "20 degrees starboard". Which is the most commonly used?

global is the coordinate system that the world uses to place objects.
so, Global (0,0,0) is different from local (0,0,0) (unless there is no distance between them and no rotation difference).

Oh ok, I understand now. Lastly, are you treating Y as the third dimension? Or Z? In my code, I treat Z as the third axis, but now that I'm looking at it, it seems that the equations I used treat Y as the third axis. Perhaps that where some of my issues are coming from.

Yea, Y is usually up and down in Global coords, and Y is usually Depth (forward) in local or camera-based coordinates.

Ok well let me then share my formulas:


Code:


That right there is the meat of what drives movement and rendering in the engine. How much of this is wrong haha :p

I'm sorry, but all I can help you with is the equation in python (similar language) right now (my knowledge of c is VERY limited).

Code:

After implementing some of your suggestions (the best I could port them to C) and correcting the inconsistencies in the vertical axis within my program, the rendering routine has acquired more stability. Scaling based on distance is still off, but response to moving your ship left/right/up/down causes predictable behavior --- the borg sphere moves up/down/left/right as excepted.... except for when our ship jumps from 255 degrees to 0 degrees or 0 degrees to 255 degrees (overflowing the char type). In cases like this, where, for example, the player would be facing 254 degrees on the xz axis and the AI is at 2 degrees relative to the ship, the algorithm thinks that the ship is 252 degrees away, thus out of visual range, when in reality is is only 4 degrees away. How would I work around this?

oh lol I thought that you were working in 360s!
I'll 'beam you up' some new code soon!

Well I sort of "map" the 360 degrees to the 0-255 range, in this fashion:


Code:

In the code above, *data is a pointer to a temporary structure that holds the local position data. Delta_[axis] is the position on the axis for the object moving minus the position for the object it is seeking towards. (for viewscreen, its player position subtracted FROM object position)

The code that handles whether or not to render is:

Code:

In THIS code, data is the same struct that the first code populates, VISUAL_RANGE is a defined constant, and the rest should be fairly easy to interpret.

Today, I succeeded in fixing the issues with the axis, and fixing the issues with differences between the angles overflowing, causing the renderer to improperly read a larger angle offset than there is. Two final issues remain in the rendering routine.

1) The calculations for scaling are wrong. As we approach the sphere, I can see it scale up nicely, but it starts off way too big. For a starting sprite size of 15x15, that certain doesn't start off at a scale of 1, or 2, or 3... or anything less than 8 imo. I've tried messing with the data types, using ints, floats. I even corrected an earlier mistake, using the ^ character for exponents, and replacing it with value * value for value ^ 2.
If anyone can take a look at the pastebin'd source and find any possible thing I may have overlooked, why scaling doesn't work, you'll be doing better than me!
https://pastebin.com/NjxP5pMV


2) This is a question directly for Mateo or anyone else who has used the C libs in this fashion. I need a way to clip sprites such that the parts of them that are outside of the viewscreen window do not render, but the part of the sprite that is within it still renders. Constants for the viewscreen's starting x and y, as well as its width and height are in the program. The examples in the libs that I have seen don't do this, although I admittedly haven't looked specifically for this. When I attempt to address this tomorrow and take a second look, if i find something, ill edit this one.

Update

Scaling fixed. This has revealed a bug where sometimes we don't see the borg cube when we reload the game after quitting it. It also reveals that projectile tracking entities needs fixing as well.

Still need conceptual help with clipping sprites.

You can set a clipping window? What is the issue.

woooooa... all the times I've scrolled up and down that file looking for info on clipped sprites I've totally missed _SetClipRegion.... Well I guess that's that solved.

But wait, are the only scaled sprite routines available unclipped?

Edit: Since there are no scaled transparent sprite routines that clip (yet), I combined the gfx_ScaleSprite() with gfx_TransparentSprite(). I also created a very large malloc() as a "graphics buffer" that I use to decompress/scale/etc. It's a 24,000 byte block of memory.

Alright, so I'm down to two remaining issues. One of them I'm working on now. The other I need some feedback on.

So when my code renders the borg sphere in the viewscreen, it renders when I increase the angle (turn the ship right) and the borg sphere moves to the left. When I move the ship to the left, however, and the angle of the ship on the XZ axis hits zero and then overflows to 255, the borg sphere disappears, as it's seeing a difference of ~> 250 degrees between the object and the ship's rotation. I added a line of code:

Code:

Not even this corrected that behavior, so now I'm confused as to where that is occuring.
Here's the code I'm using: https://pastebin.com/9sAPE4HW
Any ideas?

Edit: I actually resolved this. Turns out I was stupidly flailing around with the intricacies of overflow and correcting it, when all I needed to do was use a signed char. /me facepalms.

Edit: LCARS interface full-screen flicker removed. Field of vision overflow errors removed. FOV now maps properly to the screen width in all directions except down (have yet to test this for all scales of the AI sprite).

Update

After a bit of not understanding double buffering and then finally understanding the concepts, I figured it out, and created fairly smooth graphics rather than flickering mayhem. I implemented this only for the view screen, since it should be like you looking out a window. For the other tabs, which are LCARS displays, I left the faint flickers in, since I would think a refreshing LCARS display would have a quick flicker.

Here is a screenshot showing the Borg cube with the new graphics.


=========================
A few more things to do (Bugs):

1. Implement a shunting yard or some other form of algorithm that sorts rendered map objects by distance, so we can render them in order. (help, please?!)

2. Projectile tracking not working. (reviewing)
----- 2-a. Projectiles do not track their targets.
----- 2-b. Sometimes, pressing the fire key fires a phaser, other times it seems not to.

3. The Borg sphere not AI'ing.
----- 3-a. The Borg sphere does not seem to track the player
----- 3-b. The Borg sphere does not seem to fire as its supposed to. This is likely the same bug as 2-b.

4. The collision detection and collision interpolation algorithms might need some work. That depends on what happens after #2 and 3 are resolved.

I'm hoping for a release by Christmas.

Are you going to make the entire game universe from scratch? Or will you generate some of it? Or will all of it be generated?
Good work so far though! Loving this project!

Well, for the demo, there is going to be very little of what's intended in the game. In the demo, you'll fight one Borg sphere with standard, un-upgradeable weaponry, have a simple speed control system (no warp), and sensors will essentially be always online and locked on. The idea is to let people get a feel for *how* the game will handle, without giving too much away. In this demo, the game universe is one sector, with one ship and nothing else. I generate and spawn that ship in the initialization. Keep in mind that while this is a singleplayer demo, the finished product will be multiplayer, and a lot of the routines in this game are being designed in a fashion that would be somewhat bloated for singleplayer, but they're pre-geared towards networking.

For the long term, however, it's gonna be a lot more network-centric. I still do plan to make this as a networking game, that somehow uses the CE's USB protocol, and perhaps a computer-side helper program to communicate with a CALCnet hub. This will allow the game to eventually be made backward-compatible with the older z80's. In this version, when the *server* initializes a game world, it will generate the terrain, and that terrain will be the same for all connected units. When I get to working out how to get started with networking, I'd love to have a look at the Direct USB code Kerm uses for CALCnet, to see if it's adaptable in any way. Also, one of the features I plan to implement is allowing users to, from a computer, upload their own ship model that gets rendered for other players when they see you (kind of like a minecraft skin).

One of the caveats I'll need to overcome is how to get these sprites to the calculator from the network. 3D sprites are way too large to send in the frame update packet (which would only contain data on what is within *sensor range (sensor range because sensor range is the largest range of objects in the world that you'd ever interact with, informationally) -- location, orientation, distance, size, and if a terrain object factors like gravity, burn, etc.). I could easily send sprites related to terrain objects in the join packets, because i can use 2d sprites with a little bit of random rotation and stuff to create irregularity. But, if I were to send 3D sprites for every existing user, that would take a boatload of memory. I could send sprites for every *connected* user, and delete/add them as people quit/join, but that might cause some client lag as we receive that much data. I'm certainly open to suggestions on this.

Also I'd love suggestions on how to make the display to the left of the positional data be a bit more GUI-y. I want to move the coordinates INTO the viewscreen somewhere, perhaps leave sector on the side, and have some cooler way to display your rotation. Ideas?

Ok so I need some advice.

The Problem: When I'm rendering the weapon sprites, the weapons should seem to move from lower on the screen, and then move towards the center, and the ship. I thought of drawing triangles (gfx_FillTriange) to create a perspective beam phaser effect, but that's very hard to control with the degree I need to. I'd need to be able to calculate the starting point and ending point of the phaser beam and draw a line or series of lines. The starting and ending point may not always be on screen, especially when the game goes multiplayer and you'll sometimes see a phaser fly across your viewscreen, heading elsewhere. This seems to not be a problem with the torpedo sprites, as torpedoes are more in one place than beam-like.

The solution I'm leaning towards: Adding to the union member for Projectiles a second Position_t structure. This structure contains the coordinates of trailing end of the phaser beam and would have a "trail lag counter" field that determined how long the trail would take to begin moving with the phaser. In this manner I can create pulse phasers with a shorter counter and more beam-like phasers with a longer counter. Rather than a sprite, the phaser would be either a gfx_Line() or a gfx_FillTriangle(), going from the phaser's head to the end of its tail.


Does anyone have any other suggestions? Or does this seem like a good idea?

Would I be able to recruit some debugging assistance? I've gotten this game mostly debugged, but I'm still struggling with two remaining issues that I can't seem to remove.