This code, when run, is giving me glitchyness at the bottom of the screen, right where the TI-OS puts the x and y coords of the cursor.




.POLYAOI
identity(FFFFCFBFB7BFB7BF89ADB6ADB6B3B9BBFFFBCC67B6DBB6DB86DBB6DBB467FFFF)
Full
Full
ClrDraw
ClrDraw
DispGraph
ClrHome
DispGraph(Pic0)
getKey
ClrHome
Disp "Input Polynomial"
Disp "Expression:"
Disp 
Input →A
length(A)→B
Disp A
Pause 5000







[FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9FFFFFFFFFFCFFFFFFFFE1FF9FFFFFFFE7FCFFFFFFFFE4FF9FFFFFFFFFFCFFFFFFFFCCC73261C709CC39C7FFFFFFCC9332649324CF999FFFFFFFC39330E49324CC198FFFFFFF9F9271C992499933CFFFFFFF9FC673C9C6499C331FFFFFFFFFFFF3FFFFFFFFFFFFFFFFFFFFFFE7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE64F8FFF0FFFFFFFFFFFFFFFC64FCFFE6FFFFFFFFFFFFFFFD6DFD87EE430FFFFFFFFFFFF96D9DB66EDA0FFFFFFFFFFFF86DF9B7ECDA7FFFFFFFFFFFF709F127E1931FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7C7FFFF7BFFBFFFFFF77FFFF7DFFFFFFEBFFFFBFFFFFFFFF7FFFFFEFBFEFFFFFFF7FFFFFFFFFFFFFFFFFFFFFFFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFC6C7FFFFFFFFFFFFFFFFFFFFFFFFFF5FFFEFFFFFFFFFFFFFFFFFFFFFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]→Pic0


I will be needing sprites for Star Trek. While I can work on these myself and will if no one has the time, it may expedite the development of this project and the aesthetic appeal of the game for someone a bit more artistic to help with sprites. That being said, I need the following sprites (8x8, 3 layer grayscale):

1. A sprite for a Federation starship, facing to the left, right, away, and towards a player. (4 sprites)
2. A sprite for a Klingon starship, also facing to the left, right, away, and towards a player. (4 sprites)
3. A sprite for a Vulcan starship, facing left, right, away, and towards. (4 sprites)
4. A sprite for a Dominion starship, facing left, right, away, and towards. (4 sprites)
5. A sprite for a Romulan starship, facing left, right, away, and towards (4 sprites)

6. A sprite for a star. (Note the star itself will be comprised of several of these sprites arranged in a circular pattern, so keep that in mind [but I still only need 1]). (1 sprite)
7. A sprite for an asteroid field. (as in 6, a single asteroid field will be several of these sprites) (1 sprite)
8. A sprite for a nebula. (as in 6, several of these will be one nebula) (1 sprite)
9. A sprite for a black hole (perhaps only one sprite for this ) (1 sprite)

10. A sprite for a fired phaser (since you have a view screen, it can kind of only be seen if its right in front of you, moving either towards you, away from you, or to the left or right) (4 sprites)
11. A sprite for a fired torpedo (as in 10, only if in front of you and moving in any one of the four directions) (4 sprites)

12. Sprite for the star base (should look like a star base, so I'm not sure if we actually need several sprites for this)

As many of you know, I've been working on a Star Trek game for some time. This project is not dead, just sluggish because of RL obligations.

I am starting to think about what features can be client-side, and what must be server-side, on the hub. Here are some of my ideas:

1. Have the hub itself hold ALL the data about the players on the game...their names, their positions, etc. If I can create databases with this info and have the hub handle searching for the data, then I can do something much easier with regard to sending data (see #2).

2. Instead of having the calculator have all the data for all the players on the server, which would consume a lot of memory, I can have the data on the hub, and then when you need some of the information, the hub would respond only with relevant data. For example, if you are doing a "position update" on other ships (redrawing them at their new locations), we can send a request for new positions to the hub. Now, let's assume the maximum view range of your ship is 100. The hub would only send you back the positions of players within 100x100x100, not the guys on the other side of the galaxy.

2a. The hub itself would do the cycling, not the calculators. Once a weapon is fired, the calculators never again see that. The server adds it as an entity, and handles changing its position on correct timing, and sending data on it to the calculators. Thus the server is doing all the work and all the clients are doing is rendering it.

3. Instead of having separate routines for drawing ships and drawing phasers and photons, I can actually make them all "objects" and store their position, direction, and speed data on the hub in the same fashion. That way, I can draw them all with the same routine. This would also allow for this: if you fire at a ship and you miss, the projectile keeps going until it either goes out of range or hits someone else, without any extra code, beyond a collision detection.

4. A star base will be a server-created entity that is capable of self defense. It will belong to a team (assuming I can make team play possible). Players on that team can enter the base, refuel, repair, and equip it with weapons. Players on the opposing team can attack it, and it will defend with whatever it is equipped with.

5. When the first player joins the hub, the server will create a world and generate terrain. Terrain can include basic space, stars, nebulas, and wormholes. I hope to include planets at some point, but star bases will be the only defendable thing in v1. Basic space does nothing and is the majority of the map. Stars can damage your ship if you go too close, and have gravity (not sure how I'm implementing or using gravity). Wormholes also have gravity, but more. Nebulas are there mainly for a tactical use...they disable shields, sensors, and communication. To minimize load on CALCnet and on the calculators, when you join the world, you will only be send terrain data for the area near you. As you near the edge of that, you will exchange your terrain data with new terrain data.


Here are, as I see it, the pros and cons.

Pros

• Less demand on CALCnet itself and on the client calculator.
• Able to do more, and have more realistic combat, with less coding.

Cons

• We are relying more on the hub for data than on the individual units. Thus, if the hub can't keep up, then we have a problem.
• I will need to write routines for REQUESTING data from the hub, which I wouldn't have to do otherwise.

So here is my questions:

1. Do the pro's outweight the cons? Should I adopt this new strategy?

2. Anyone willing to help out at all? I don't have all the time in the world to make this lol?

I got Unit 1 of my comprehensive z80 tutorial up at Google Docs. The link is below. It is open to revision by all, so feel free to edit away. I actually want it to be longer.

https://docs.google.com/document/d/16kb_uChpEkaDiLcn2bz_FHQMGJtsLLa2MgvrZ9YX5Kk/edit

Ok, I had a few people helping me out on certain aspects of Zelda, but that was months ago and I have since lost those records. If you were working on something, please let me know. I am going to put together a dev team to help me with aspects of Zelda that I cannot program myself. The entire dev team will be credited for the release of this project.

Below is a list of things that need to be done:

1. Artificial Intelligence
2. Collision*
3. Bullet-like shooting system for hook/longshot and bow
4. Smooth scrolling rendering of greyscale graphics

*Collision: The collision with enemies I'm assuming is part of the AI. As for collision with tiles, I just need a way to convert the pixel by pixel Player movement into a way to check if collision with a tile has occurred. To clarify, the variables PlayerX and PlayerY are in pixels. If someone can tell me how to convert that number into a tile value, I can handle checking for movement onto illegal tiles myself.

Beyond that, there are a few other things that need to be done.

1. Compress map data (I can provide the data here, but the utilities will not run on Mac. Someone may need to run the data and post the compressed here).
2. In game-dialogue. I can handle this.

I believe that I once read about an idea by another programmer to make an Archiver of sorts, with the capacity to work with the DCS file structure. I learned on Cemetech that he put the project on hold. Reading this sort of made me want to work on a similar program myself, mainly for practice with different data types.

It'll work similarly to WinRAR for Windows and Stuffit Expander for Mac. That's why I name it CalcRAR. This program will create an archive file, a specially-formatted program with data that CalcRAR will read to determine what files to create, data to put in the files, and where to put the files. The file, after creation, will be compressed. When it is read, it will be decompressed. The best part, you can run this program just as you would anything else, given CalcRAR installed. The Archive is designed with the DCS AP feature, so when you run it, CalcRAR unpackages the Archive, automatically runs the program, then returns to CalcRAR, which removes the unpacked files and quits.

The reason I posted is because I need some advice. Is RLE the best compression to go with here? Or is another type better? And I may actually need some help implementing it.

Can someone write me up one if they have the time? I started to write one myself, but got confused. Below is what I have so far. Can someone please help me out with this. I'm looking for the routine to prompt for an equation, allow you to press the down arrow for subscripts, make the second character of a two-character symbol lower-case, and make the y= button give the arrow.

ReceiveEquation:
    bcall(_ClrLCDFull)
    ld  a,0
    ld  (penCol),a
    ld  (penRow),a
    ld  de,saferam1+1
    ld  a,0
    ld  (saferam1),a
    ld  a,0
getKloop:
    bcall(_getCSC)
    jr  z,getKloop
    cp  $01
    jr  z,switchnumeric
    cp  $04
    jr  z,switchalpha
    cp  $02
    jr  z,backspace
    cp  $09
    jr  z,done


switchnumeric:
    bit 0,(TextInputFlag)
    jr  z,getKloop
    ld  hl,NumericCharMap
    ld  a,(penRow)
    add a,3
    ld  (penRow),a
    res 0,(TextInputFlag)
    jr  getKloop

switchalphaup:
    bit 0,(TextInputFlag)
    jr  nz,getKloop
    ld  hl,AlphaCharMap
    ld  a,(penRow)
    sub 3
    ld  (penRow),a
    set 0,(TextInputFlag)
    jr  getKloop

backspace:
    ld  a,(saferam1)
    cp  0
    jr  z,getKloop
    dec a
    ld  (saferam1),a
    dec de
    ld  a,(penCol)
    sub 5
    ld  (penCol),a
    jr  getKloop

done:
       
AlphaUpCharMap:
    .db 0,0,0,0,0,0,0,0,0,0
    .db "WRMH"
AlphaLowCharMap:

NumericCharMap:


If I ask for another text input routine, I give you guys permission to curse me out. .

I'm trying to accept chemical formula input. In this routine, the first letter prompted for should be only uppercase. The second should be only lowercase (those are the only two allowed options). Pressing the down arrow key should allow you to type a subscript (there should be a designation in memory to indicate where the subscript starts and ends). Pressing the up arrow allows you to type superscript charges (2+, -1, ect.). Again, there should be a designation where the superscript starts and ends. You should be able to type parenthesis at any time. Can someone write such a routine for me? I'd even use the one out of the Balancer app, if I know who wrote it and have permission to use it.