calcCos:
ld b,-64
add a,b
calcSin:
cp 128
jr nc,greaterT128
cp 64
jr nc,greaterT64
jr sin_getEntry
greaterT64:
ld b,a
ld a,63
sub b
jr sin_getEntry
greaterT128:
ld b,128
sub b
cp 64
jr nc,greaterT64
jr sin_getEntry
sin_getEntry:
ld c,a
ld b,0
ld hl,sinLUT
add hl,bc
; hl = 8.8 FP result
sinLUT:
.db 0,3,6,9,12,15,18,21,24,28 ; sin(0-9)
.db 31,34,37,40,43,46,48,51,54,57 ; sin(10-19)
.db 60,63,65,68,71,73,76,78,81,83 ; sin(20-29)
.db 85,88,90,92,94,96,98,100,102,104 ; sin(30-39)
.db 106,108,109,111,112,114,115,117,118,119 ; sin(40-49)
.db 120,121,122,123,124,124,125,126,126,127 ; sin(50-59)
.db 127,128,128,128 ; sin(60-63)


Two separate questions, to resolve two issues, whereupon which I will be releasing a game.

1. Is there a simple way to take an angle (period 0-256) and get an x vector and a y vector? I know that x is sin and y is cos, but i need the result to be a SIGNED 8.8 FIXED POINT.

2. If you have a sprite of size nxm, is there a way to, using its distance from you, scale its size so that it looks like its farther or closer and then render it?

Language is asm. Thanks.

Im not entirely sure. Tall sprites for sure. And some level of greyscale, most likely 4, since I need to draw them on a black image. PM me for details.

Progress Update

Working on Firing systems and power cycles now. Having trouble implementing a 3D-targetting sensor, but have a template for how locking occurs, memory-wise.

I don't believe I've put the details of the game's map on here yet so here it is..

You have a 2-byte sector coord and a 2-byte location coordinate for each of 3 axes, so we're talking a map size of 65,536 x 65,536 in each direction. When the map for the server generates, it does so in objects, so for instance, a star might have x,y,z sector and location coordinates for the center, a radius, and data about status effects it might have, like gravity, burn, etc. When map data is sent to the client, the server only sends you data on terrain that would be picked up on your long range sensors, which would be like a sector or two in each direction. So we're not overloading the calc with data, and the server can handle that data.

TL;DR, as always but I skimmed through some of it and I'm glad you are still planning gCn support (especially with the Spark Core-enabled gCn development and the possibility that one day any USB wifi dongle becomes useable) and more importantly that this project is still alive

It never quite died DJ. I had to stop work on it a few times bc of RL things, and lack of skill on some things, but with a git repo where I can let a few other people help, and a vastly improved knowledge of asm, I feel like this time will be it!!!

As the mostly-under-wraps progress on Star Trek multiplayer nears the 50% mark, I thought I'd share some of the new planned features for the game, as well as share what is done.


First off, the game's source code is being hosted privately, on my private web server. Access is via ssh. Anyone who wants to help with what's left can comment the topic and I'll PM you the URL and password to the repo.






Shields


I have slightly revised the way the shields work. Originally, it was intended that weapons have an energy damage rating and a solids damage rating, for damage to shields and ship, respectively.


The new system uses a payload rating for a weapon and a dispersal rating for a shield. The shield's current dispersal rating is equal to its max rating multiplied by its current percentage health. For example, imagine a weapon with a payload of 10 is fired at a shield with dispersal rating of 10, at 100%. The weapon impact damage is reduced as such 10 - (10 * 100%) which equals 0, and the shield health is reduced by 10. The next time the damage occurs at 10 - (10 * 90%), which equals 1. So 1 damage is dealt to the ship, and full 10 damage to the shields. **If a weapon's payload is less than the shield can block, no damage will be dealt, but shields will not gain health (sorry :p). If the weapon's payload exceeds the shield's blocking ability, even at 100%, the weapon will still break through.


You will have the ability to install more than one shield module onto your ship. One module will deplete its health, and then be replaced by another. In this case, however, as long as you have one other active shield module that is online, no damage will break through, even if the current module's percentage of health drops.


Sensors and Multi-targetting


The ability to install more than one weapon module will also enable you target your ship's weapons at either one target for combined damage, or to target each module at a different ship. Sensors will enable this by displaying three different targeting interfaces. Press a key to toggle between single target and spread target.


AI Borg Cubes


In keeping with the series, the server will control several Borg cubes with powerful weapons and shielding, designed to be attacked in groups, or fled from if you can run. They will be occasionally spawned in some distance away from an online player and will pursue that player or whatever player moves closest.


Stealth Tech


You can purchase (using points) and equip stealth tech modules. Stealth tech includes: (1) cloaking devices, a level 1 cloak automatically shuts off if you fire, a level 2 does not, and the cloak drops if the module looses health, (2) EMP pulses, which knocks all power systems (warp and impulse) offline for a time, which knocks all systems offline for just as long, (3) viruses, which damage a targeted ship. You may also emit a scrambling signal, which stops all sensors in a certain range from working. Lastly, you may scan another ship to gain info about where their systems are, their shield modulations, etc.






Currently done in the game is the opening menus, most of the CALCnet routines. Still to be done, rendering and the hub. I should have a beta done in a few months.

Well, I suck at spriting but I'm sure there are pixel artists out there ready to help out. It'd be really awesome if you bring this to a completed state.

I have a lot of good ideas for this game. While I could complete it alone, it would take a long time, especially since I'd need to learn graphics rendering, AI, bullet code, and how to do that anti-aliasing stuff. If I can get spriters (and even a mapper, if I'm lucky), that eliminates that. Then I may have a look at the code for another RPG's rendering system to get some ideas...