A few teasers from the upcoming 0.0.94 release.

1) Custom graphics packs supported. To indicate that the graphics pack is custom made (so the client doesn't do a normal version check), you use the following settings in convimg, in addition to the normal ones.
lut-entries: true
header-string: "\xff\xff"
Special thanks goes to MateoC for implementing the `lut-entries` option in convimg... it simply moves the offsets LUT into the appvar itself, rather than leaving it defined in the program. This allows the program to load any array of sprites as assets. You will still have to keep the same sprite order, however. Refer to the link I posted previously for details.

2) The splash screen has been completely reworked.

The menu interface is cleaner, and the networking status is indicated by icon now, instead of by text. A green USB icon indicates that the serial device is ready, a red icon indicates some error. If we implement nanotube, or internetce support, an icon will indicate if the program is preferring that connection.

3) The program now alerts you on the splash screen if your graphics version is incompatible.

The incompatible graphics is triggered in one of two ways:
 a) You are using a default sprite pack and the version header does not match the one set within the program's `reqd_version` array.
 b) You are using a custom sprite pack (version string 0xff, 0xff), and the number of sprites in the LUT does not match the number of sprites in the program build.
Either of these being the case causes the above alert to show up, and the "Play Game" menu option to just return you to the main menu.

All splash screen and error/alert icons are built directly into the program to ensure they are available... the asset pack only supplies stuff used for the game.

Update
* First Pre-Release *
== TI Trek Client version 0.0.92 Released ==

At long last, the first pre-release for TI-Trek is finally out. The current version of the client software provides the ability to login or register on our server (the TI-Trek server), as well as to disconnect. It also comes with an autoupdate system, to allow us to push updates to clients easily (the updater simply compares your existing version string with the version string for (1) the latest client, and (2) the earliest compatible client. If your client version is out of date, but still compatible, you will be given the option to autoupdate. You can say yes or no, either way, you will log in. However, if your client version is not compatible with the server, you will not be able to log in unless you either autoupdate or update manually.

To actually perform the autoupdate, the server will fetch the TITREK.bin file within the latest client directory and begin sending the data inside it over the TCP socket, in 1024-byte intervals. The client dumps this data into a temporary program file. To conclude the transfer, the final packet of the autoupdate is empty, which tells the client it is done. The client will then call ti_Close(), then rename the program to TITREK, then call an assembly routine that reloads the new program into RAM, and starts over. Meanwhile, if the latest client version has a "gfx-force-update" flag set in the config for that version, the server then proceeds to send a new graphics pack to the client, using the same method. Once again, an empty packet finishes the transfer, and then the graphics are reinitialized.

Meanwhile, the Web Deck (the GUI front-end for account management) for the game has also seen work. The server's IP is play.titrek.us... connecting to that with the bridge connects to the game server, but going to that IP in a browser takes you to the Web Deck (it's also accessible through the footer of the main site). To prevent spam accounts and to ensure accounts are active, only active users who have registered an account with their calculators can access the web deck; Once your account is created there, you can log in using the username/password you used. When logged in you can modify your Display Name, Password, and Email Address, as well as upload custom graphics to replace the existing ones (not yet implemented). Also admins and moderators can see all registered users' display names, emails, and usernames (but not passwords). They also get a printout of the server's console that refreshes every 30 seconds (*can anyone tell me how to make a widget like that scroll dynamically to the bottom- as in load in scrolled down, and scroll down as more content is added? it's a div with overflow auto.*) via ajax.

Special thanks to:
beckadamtheinventor: server dev
commandblockguy: bridge dev
me (ACag): client dev, web dev
graphics devs: Eaghan, Pieman, Ampersand, TurquoiseDrag0n, Argus, epsilon

Downloads Available at: http://titrek.us/downloads.php
This program requires the following C libs: fileioc, keypadc, graphx, srldrvce, usbdrvce.
To use the last two, you will need to obtain the srldrvce branch of the toolchain, or ask one of the project devs for a copy.

I posted this to Cemetech and Omnimaga as well.

QuoteI would even propose calling TI's bluff on something. Write TI a letter, signed by a EVERY major calc development community - Cemetech, Omnimaga, Codewalrus (unity is important on this), informing them that if they do not revise their decision on C/asm, and implement exam security in a way that is conducive to teaching, learning, and doing programming, we the community will be designing, releasing and marketing our own calculator to compete with them. And if they do not walk it back.. actually follow through.

There is no action legally they could take to prevent this: it would be our own hardware and programming, no copying of names, symbols, anything. Free market, people can compete with whoever they want.

UPDATE

Project TI-Trek has now been successfully compiled with full USB support... using srldrvce. Due to wonkiness in CEmu's usb support, it is no longer possible to test networking on the emulator (the lib cannot initialize the driver properly). I will need to move to on-unit testing for the remainder of client-side development of this project. I have gotten written the ntwk_Login(), ntwk_Register(), and ntwk_Disconnect routines, which are the first aspects of gameplay that will be tested. While I have been hard at work on client-side things, commandblockguy has been working on a USB=>IP bridge similar to the one Kerm devised for gCn over DirectUSB. And last but not least, beckadamtheinventor has been hard at work developing the server side of things... from map generation to control codes and saving/loading data. For those interested, the server is written in Python, runs on port TCP 1701 (the registry number of the Enterprise), and uses json for long-term storage. It stores connection descriptors to an array of Client objects, which also contain the IP address, username, and some more information about the connected user.

The game will implement semi-accurate space physics. When the map generates, the server pre-generates some paths for celestial bodies using formulas for things like gravity and inertia. Those objects will follow those paths every tick, scaled to the time-rate of the game. In addition to fluidity in space (meaning planets, starbases, etc will not be in exactly the same spot every time you look for them), other objects will pose a threat... black holes will exist and end your journey very fast. Stars will tick their life cycle and then die in a manner determined by their size. Major celestial events, such as star death or planet destruction will result in a path-adjustment for entities within gravitational range of the changed section.

Also, after discussion with beck, another feature will be added to the game, called a synthesizer. This component will allow you to interact with materials you own on a molecular level to enhance them in certain ways. For example, say you place a piece of tempered steel into the synthesizer. You can then select from reserves of any type of element, and the properties they enhance/detract from will most reflect their actual chemical properties (toughness, deflection, malliability, heat resistance, etc). Say you choose to combine the tempered steel with a type of element that increases toughness but decreases heat resistance. You would wind up with steel (hull plating, for instance) that provides a boost against projectiles and physical impact, but is damaged more by heat sources, phasers, and the like. You could also, for instance, infuse your hull plating with a mineral that enhances magnetism, which in turn enhances your shield deflection. And if you attempt to combine unstable materials, you could, for example, wind up inflicting feedback damage to an attacking enemy, but also winding up with vastly increased damage to your own ship.

For anyone wishing to have a look at the code-base so far (yes, it will need some optimization), here it is. I will say, in my opinion, at least the network handling is remarkably well-organized... for what I usually do.
https://github.com/acagliano/titrek-calc

TI-Trek Icon-Making Contest

I first announced this contest on Cemetech, but I am hosting an Icon-Making Contest. The jist is... I want to replace the Icon of the Enterprise in the Tactical screen with a custom icon and I'm letting the potential user-base have a first crack at it.
Objective: Design two 32x32 sprites, one a top-down view and the other a side-view (no shields need included)
Submit: Submit to me at [email protected].
Prizes: (1) A TI-Trek contributor plaque or badge, (2) Inclusion of your icon in the default sprites, (3) A mention in the credits.

The image I am looking to replace is this one:


Updates

Not much in the way of actual coding or gameplay, mostly some backend updates and changes.
srv.titrek.us has seen the addition of a UI customizer, an upload form that lets your save custom sprites to replace the default sprites that comprise your UI. Once Mateo fixes convpng's inability to run on Raspbian, I plan to add the ability to actually build the graphics into an appvar for download within your user portal.

Server-side, we have the beginnings of a "server". As of now, the server is capable only of log ins, log outs, some debug messages, and sending specs info. I have also written the appropriate systemd files to enable the `service titrek start|stop|restart|status` ability, as well as server start on boot.

Client side, actual connectivity is hopefully close. I am waiting for an "official" build of the C toolchain to include the USB serial device driver and/or the IP libs... once this is the case, we will be ready to begin testing of basic connectivity between calculator and server (the USB serial mode will require a "bridge" program running on your computer, much like Calcnet did; the IP lib should require only a USB-ethernet cable or adapter). Once we verify basic server functions working, we will begin to implement and test components of actual gameplay.

Of course, throughout the process, beta and alpha releases will be available through the Project's website for the community to test, http://titrek.us, but I ask you remember that beta and alpha releases are inherently unstable and prone to... issues. Consult the changelogs and the bug reports to see what, if any, things you should watch out for.

UPDATE

Progress has been made on the User Interface for TI-Trek. Here are some screenshots:
The Main Systems module overview screen


The Tactical Systems module overview screen


The module configuration/info popup, accessible by pressing [Enter] on chosen module


Some changes to the power system setup also. Module efficiency (how well it performs its task) will be a function of module battery charge (current power level * 100 / max power storage) multiplied by power draw setting (set power draw / base power draw). Power draw meaning how much power a module will take from its source (core, auxiliary, or internal reserve) every power cycle. Each module will also have a maximum draw, which is the maximum amount of power a module may be set to draw before the module incurs a damage penalty every power cycle. For instance, if the module's max draw is 8 and you have it set to 10, the module will take 2 points of damage every time it draws power. This means you can set a module to use as much power as you want, to super-boost it, but keep in mind the higher you set this, the faster the module takes damage.

A few major updates to this project, which is very much not dead, just slow moving due to RL stuff.

Anyway. The project has been split into 3 distinct segments, each with a different team working on it.
The client side program, for the calculator, is being mainly developed by myself with some help from beck on the 3D rendering of the map.
The server is being worked on by myself, Greg, and beck, with a web-frontend being worked on, which I am working on solo.
To interface the two, we are awaiting the completion of the USB device library in the C libs.

The web frontend will be at http://srv.titrek.us (please do not register on there yet), with the main project page at http://titrek.us. I am hosting the server for the time being on the raspberry pi 3, but am looking to upgrade that to the new RPi 4 with 4g of RAM, which will likely be the final resting place of this server.
Anyone wishing to contribute to this goal, feel free to donate at http://titrek.us/contribute.php.

Update -- 0.65 alpha

Significant additions to the program:
1) Phasers/torpedo modules added to the ship. Only phasers shoot currently
2) Ability to quick fire or charge fire phasers, at different power costs.
3) Splash screen added
4) Navigational display for viewscreen (overlay) added, indicating ship rotation and pitch, as well as current sector position.
5) targetting display for viewscreen (overlay) added, with a crosshairs that moves on the screen and text showing the type of weapon we are firing.
6) Bug with rotation/pitch removed, thanks to MateoC

So I'm posting here to see if anyone wants to help me out with sprites for the Star Trek multiplayer demo. Currently requested sprites are:

1. Phaser bolt (weapon)
2. Photon torpedo (weapon)
3. Quantum torpedo (weapon)
4. The Narada (from Star Trek 2009) (ship)
5. Weapon-on-shield clash flare (vfx)
6. Explosion (vfx)

For the weapons, either a 32x32 or a 64x64 will suffice.
For the Narada ship, you can use your own discretion as to the size of this sprite. Keep in mind that the Narada is a massive ship.
For the vfx, please keep to a 32x32 or a 64x64.

_Animations_
Also, something I'd like input on. I want to show on the screen some sort of spark rain effect that you'll be seeing periodically when your ship's hull integrity module is below 25% health. Examples of the effect I want to create are here:
https://youtu.be/56iTxduUacs?t=6m41s
https://youtu.be/eSnzrxNIJd4?t=1m43s

Also if I want to shake the screen in response to a weapons impact, what's the best way to do this? In C. Substituted "screen corruption" effect.

UPDATE -- 0.50 alpha-ish

Ok, update time!!
This game took a bit of a hiatus, as many of my projects do from time to time because of real life, skill building, and other stuff.
However, I did some code reorganization at the start of the summer, then set out on an endeavor to have a working demo of basic combat (single player) by the end of the summer.

Attached is the current pre-demo release. This version is functional but has no AI or rendering engine yet. That is what I'm working on now... 3d rendering, weapons and targeting, then wrapping everything up, optimizing, and releasing. That being said, I'll talk about some of the cool features already implemented:

1. Ship Status Icon
At the lower, left side of the screen there is an icon that shows your ship and your shields. As your ship takes damage, you'll notice the shields first. They start off electric blue, then degrade to yellow, then to red. Additionally, within the ship itself, which is normally grey, sections of the ship will turn red as systems are damaged. Hull integrity causes a small filled red circle when it reaches <50% in the saucer that gets larger when hull integrity fails. In addition to that, the nacelles turn red when the warp drive is below 50%, the aft of the ship turns red when impulse, life support, or the warp core fall below 50%. As of now, this icon is locked to an Enterprise-ish shape, as are the indicators. If/when I allow icons to be customized, I'll have to modify this to match.

2. Warp Core Failure
When the warp core system is damaged to less than 25% health, the program begins attempting to trigger a warp core breach. The odds of a core breach are 1 / system health * 10. So, for a warp core at 24% health, the odds of a breach occurring are 1/240. If the warp core is at 10% health, the odds become 1/100. Once a breach is successfully trigged, a timer begins. You get 1000 game cycles to avert the breach or your ship is destroyed. I have yet to clock how long that actually is. You can avert the breach by (1) Repairing the warp core to above 50% health (see Repair), or (2) Pressing the [Del] key to eject the warp core. The ejection occurs and spawns a critical warp core behind your ship, on a slow trajectory moving backwards (relative to you). Doing so immediately stops all power flow to your ship, meaning if you have no auxiliary power module installed or no warp core to refill the slot with, you'll lose power fast! The counter continues from whatever it was at when you ejected it, and then explodes in a MASSIVE detonation that can significantly damage your ship if you're too close.

3. Power, Inventory, Core Breach, Life Support Alerts
When any one of these four things need attention, there is an alert dedicated to them. The power icon appears when any module is unable to fulfill its power requirements, meaning that your power generation is no longer effective enough to keep your ship powered. This means that it is time to (1) Bring unessential systems offline, (2) Repair your warp core (the health of your core determines your ship's power output), or (3) Switch to an auxiliary power module (if installed).
The Inventory status alert appears when an active torpedo module has exhausted it's supply of selected torpedoes (unimplemented).
The core breach alert appears when a warp core breach has been triggered, and will disappear if the core is repaired or ejected.
The life support alert appears when the life support system hits 0% health or is turned offline. If life support is not repaired and brought back online within 2000 game cycles, your crew dies and you lose.

4. Repairing Your Ship
Any module may be repaired, including shields and hull integrity. Repairing a module stops it from being supplied power, stops it from functioning, and expends a lot of power to repair it. Every 5 game cycles, the module draws its current power default and gives itself 1 unit of health. For a starting ship, this means that it takes a module 250 game cycles to fully repair to 50 health, and costs 250 power to do so.
* A repairing module is treated as OFFLINE. This means that if you are repairing your shields, they will not function. If you're repairing your hull integrity, it will not give you extra damage protection. If you are repairing your warp core, it will stop generating power. The only modules that will function while being repaired are your engines (warp drive/impulse) and your weapon systems.*

5. Damage Calculation
Damage in game occurs as two factors: shield damage and hull damage. Phasers or other energy weapons deal more damage to your shields than to your hull, while torpedoes will deal more damage to your hull than your shields. Notable exceptions will be the Narada torpedoes that will deal staggering damage regardless and disruptor phasers, which will be somewhat balanced against both.
First, the current health and current power configuration of your shields are calculated and multiplied by the shield's damage resistance value. This is the amount of damage that your shield is capable of repelling at 100% health and 100% power. To start, this number is 5. Most weapons you'll encounter at first will deal 1-3 damage. If your shields are at, for example, 60% health, they will be capable of blocking only 3 damage. If you were to then set your shields to use 200% power, they would become able to block 6 damage. In this way, you can boost your systems to help you out in combat, but at a cost (see Boosting).
The shield damage value of the weapon is subtracted from the shield's health, resulting in shield damage. The calculated damage resistance value is subtracted from the weapon's hull damage. If this value becomes 0 or less at any time, we stop calculating damage.
We then read out the damage resistance value of your hull integrity module. If hull integrity is 50% or higher, that number is subtracted from the weapon damage. If hull integrity is <50% but above 0%, the damage resistance becomes 0. If hull integrity is 0%, the module's damage resistance is added to the incoming damage. This emulates a damaged hull becoming less effective at protecting the interior from damage. Any remaining damage is applied to a system currently chosen at random, but eventually to be chosen based on the direction of the incoming weapon compared to the direction of your ship, allowing you to target specific areas.

6. Boosting Systems
Any system, except the warp core, may be boosted to allow it to perform more effectively. Here's a list of what boosting a generic system will do:
Shields: Increase damage resistance
Hull integrity: increase damage resistance
Life Support: unable to be altered
Warp Core: unable to be altered
Warp Drive: Increases maximum attainable warp speed (to a max of +5 speed)
Impulse Drive: Increases maximum attainable impulse speed (to a max of +2 speed)
Sensors: Increases maximum sensor range/targeting range
Phasers: Increases phaser damage
Torpedoes: Increases torpedo speed
Transporters: Increases transporter range
* A boosted system will use power at a faster rate than it is being recharged, and eventually run out of power and stop working. Use boosting sparingly. *

7. Warp/Impulse Speeds
The ship has 4 average impulse speeds:
1 field / cycle = 1/4 impulse
2 fields / cycle = half impulse
3 fields / cycle = 3/4 impulse
4 fields / cycle = full impulse
certain ship types and a boosted impulse module will allow additional speeds < 10.
A damaged impulse module reduces the maximum impulse speed.
The ship has warp factors 1-9, with speeds in between the major warp factors. Each warp factor increases the speed by it's factor.
Warp 1 = 10 fields / cycle
Warp 2 = 12 fields / cycle
Warp 3 = 15 fields / cycle
Warp 4 = 19 fields / cycle
Warp 5 = 24 fields / cycle
Warp 6 = 30 fields / cycle
Warp 7 = 37 fields / cycle
Warp 8 = 45 fields / cycle
Warp 9 = 54 fields / cycle
boosted warp core max = 59 fields / cycle
Intermediary warp factors supported, for example, 16 fields / cycle equals Warp 3.5.
A damaged Warp Drive module decreases the maximum speed to a minimum of 10 (warp 1) unless the module is completely destroyed.

Version 0.7b:

- Smart-Detect ProgRun hook added.
- Settings menu added.
- A number of significant GUI enhancements

**Early Access Beta Release** A suite of calculator security tools that actually functions, unlike many of the fake tools that just search for names like VIRUS, or don't scan at all. This program already has the ability to: - Save and update a database of all Programs or Protected Programs on your calculator, consisting of their names, sizes, and a 24-bit checksum. - Compare the current version of the program with the version in the database, and inform you if the size or checksum don't match. - Ability to scan your programs/protected programs for byte sequences that are potentially hazardous, via a virus definitions file that will be community-sourced. - Save your calculator's date and time settings in a secure location, thus preserving it across RAM clears. Every time you run this program, the date/time are either silently re-saved (if later) or restored (if earlier). Upcoming Features: - Ability to view/modify virus definitions on calc. - A firewall to integrate with any networking protocols devised for the CE. - Program running hook to allow the virus scan or checksum scan to be run on a specific program before it runs (disable-able)

Concurrently to Star Trek for the CE, I've been putting together a Slender port. I decided to update this project while pushing forward on Star Trek because the rendering system is essentially identical. However, when I built the project, I started getting a weird glitch. I've enclosed a screenshot of it, as well as a link to my source. Anyone who has made a pseudo-3d engine (2d map to 3d graphics) is welcome to take a look and see where I'm going wrong.

The issues:
1. Moving causes sprite double-vision, followed by the totally wrong sprite.
2. You see nothing on the map except Slenderman and a car in the same location no matter what, in spite of the positions of everything being random every time.

Here's a link to the source, for anyone wishing to review: https://bitbucket.org/anthonycagliano/ti-slender-ce/.

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.

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 resolution: I could give every phaser a *trail length* value that's like some % of the weapon's speed. For each phaser, we calculate the phaser's position and the trail's ending position, draw the phaser in position, and then draw a line or triangle from the phaser to the trail end. GregsAStar also suggested stretching the phaser's sprite out so that it goes from the phaser's position to the trail's end.


Does anyone have any other suggestions?