Yea, that 3D engine is definately something I want to use. It seems to look beautiful, but im not entirely sure it would be compatible with my map format.

Quote from: c4ooo on December 19, 2017, 04:55:07 PM

Quote from: ACagliano on November 19, 2017, 10:26:12 PM
For full 3D, I could make 16x16x16 models for each item, leading to an overhead of 4096 bytes per object,

ehh this isnt how you should be storing 3D models. 3D models are stored as a a bunch or vertices and faces made from those vertices.

oh. Can you give me an example? Would this require more or less a) memory and b) processing power to use than a series of sprites of ships from various angles?

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

** If anyone is willing to assist me in debugging, let me know!

I'm hoping for a release by Christmas.

Update

Field of Vision issue resolved.
Remaining things to do before demo: Fine tune where things show up on screen (x,y coords), and how I map the FOV to the screen over varying scales; Resolve bugged entity tracking algorithm; Remove flicker in LCARS interfaces.
Firing works---ish.

Hey guys. Sorry for the delay in updates.
As of now, rendering has improved substantially. Scaling is fixed, as is half of Field of Vision. Sprites now also clip to the viewscreen.

What is remaining are the following two bugs:

1) Your ship starts at an XZ angle of 0 and a Y angle of 0, a vector of 0,0. The other ship is in the viewscreen, at an angle of 3 degrees on the XZ and 0 on the Y. It appears onscreen. If I rotate my ship to the right (angle values increasing), the other ship moves off to the left as it should. However if I move off to the left (decreasing), once the XZ angle for the viewer drops to 0 and then loops to 255, it registers a difference of 252 degrees in the angles, and thus the enemy ship vanishes, despite actually still being 4 degrees away. I've added this code: if( diffXZ > 128 )   diffXZ = 256 - diffXZ; In an attempt to rectify this, to no avail. Link to code for that here: https://pastebin.com/9sAPE4HW

2) My entity tracking algorithms seem to not work properly. Projectiles do not appear to track their targets, nor does the AI seem to track the player, and since they both use the same AI subroutines, it would make sense. I DO need #1 fixed before I can resolve this tho.


As far as video footage, there are some animated screenshots on my project page: http://clrhome.org/startrek/'s gallery tab. There is no full gameplay footage yet, as the game isn't stable enough for that yet.

As far as what this is based off of.... there is a Gameboy Star Trek TNG game that was the inspiration for the LCARS interface and rendering system and sensor dialogs I will be using. As far as other calculator games go, tifreak has plans to make a singleplayer Star Trek game, though he's still learning C and he has access to this repository as well to see some code in action. THIS particular game, while the demo's will initially be singleplayer demos, eventually PvP between two calculators will be introduced as a precursor to networking via the CE's USB port, with an eventual backwards compatibility for CALCnet (at which point I'll open source this for porting to the monochrome calculators), using a CALCnet hub. This will allow older z80's to connect, and I'll probably have to write (or outsource the writing of) some sort of computer script to convert the CALCnet stuff into stuff the CE can read over USB. I might ask Kerm Martian if I can take a gander at his Direct USB stuff at that point.

I need help debugging my rendering routine. Anyone fairly experienced with C and rendering who can take a look at my code?

Update

An alpha demo is almost here. Got pretty much all the basic combat systems complete. Just have to add in phaser/torpedo sprites, rendering, and target tracking. Then work out any bugs in the firing/movement/rendering system. Here's an image with the demo opponent, a Borg sphere, rendered on screen.

Thanks for the comments guys. Gotten a bit more progress done.

This is the Weapons Control system. Here you can see what weapon class and type are equipped, their damage rating, shield and hull efficiency, module power setting, module health, and eventually the name of the entity or player the module is currently targetting (via targetting sensors). You'll be limited to 3 weapons modules. An unset module simply doesn't show up, and an offline module shows up red.



And a slight modification to the Mains system status panel. There's now an online/offline indicator, and pressing Mode with a module highlighted toggles that.



v0.0.18-pre  __ Saving Ship/Player data officially added __

Thanks. Poll added!

I've been talking about it for a while. Asking questions about how to do this or that. But without any real progress.

Scroll down for a question I have about ship/terrain assets.

Well as of the past week or so, that has changed. I sat down, turned off my Minecraft (with great internal suffering) and got to work. Over the past week, I succeeded in creating the shields, the major non-combat systems, damage reception, power control, and more.

At this point in time, there is no networking implemented and the file is quite large (~15kb). Much of this is due to graphics and AI calculations which, when networking is implemented will no longer be present. The intent is also to hold graphics server-side and send the relevant sprites to the calc during runtime, which will be saved in a temporary assets file. Also, as Kerm told me that CALCnet will likely not be a thing for the CE due to differences in network protocol, I'll probably use the existing USB protocol on the CE with a computer side program to send data to the hub, which would have the ability to interact with connected CE's and CALCnet, allowing the color and monochromes to play on one server. I'll also open source this when done to allow it to be ported to the CSE.

But more on that later. I have very little left to do before I can release a demo. Basically just AI ship control, player ship control, rendering the viewscreen, and firing. In the scope of what I've done already, that shouldn't take too long.

Now, feast your eyes on some screenshots:









The Question:

This game is played in a virtual 3D world. The map objects and ships are technically 3D. My question is, would it be better, both in terms of rendering speed and data size, to create several versions of each sprite, to view the object from different angles, or to create full 3D models for the ships and the spherical map objects (the irregular objects will be rendered differently). For full 3D, I could make 16x16x16 models for each item, leading to an overhead of 4096 bytes per object, which if it's in an external assets file on the CE isn't a major issue. When this game eventually gets backwards-ported to the monochrome calcs, we'd be talking about 512 bytes per object.

If the common consensus is the latter (3d models), is there someone here who has experience making them?

These are CE sprites, yes.

My sprites are 16x16 for the environment, such as walls, fences, and things like that.
The sprites for objects are different. Trees, the dead trees (from slender t8p), the silo, and rocks will end up being tall sprites. I had 8x16 in mind.
The car/oil tanker will probably be a weird size, likely wider than taller.

As far as the environment, keep in mind these sprites should appear as if they are being viewed at night. Now, I suppose I could always apply a darkening mask to the screen. Or darken the sprites. Not sure which route to go. The trees should be spruce trees, so darker leaves. I'll need a redd-ish brick wall sprite and a white/blue wall too. The red version should be included in the zip, but will need to be resized.

256 colors I can use. And yea, i do need all of the tree.

I realized I don't need TokenIDE, thats for something else.
I created a set of sprites, but I'm thinking I'll split them into two sprite sets... one for environment, one for objects or entities. The environment sprites will be 16x16 and the object/entities sprites will be 8x16 (objects/entities would be page locations and slenderman. Environment sprites would be the wall, fence, rock, etc).

I've enclosed a zip of the sprite set i've made so far. Sizes may have to be adjusted. Can someone who is better with pixel art than me PLEASE touch these up, because imo these are embarrasing.

So after trying time and time again to run TokenIDE using wine and mono for the BasicColors palette, I am finally giving up on this program. Therefore I need either a sprite maker who can run TokenIDE, a version of TokenIDE that works on OSX, or the BasicColors palette (as a file?) for me to import into Gimp.

Thanks! I've started working on making modifications. Now, for this raycaster, on a 320x240 screen, what sprite sizes would you guys recommend? This algo uses 64x64, but also for a larger screen size