Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - ACagliano

Pages: 1 [2] 3 4 ... 7
TI Z80 / PolyAOI v6?
« on: March 28, 2014, 05:10:17 pm »
So here's a poll. My project is an update to my Polynomial program which aims to provide:

1. Chained parsing of polynomials. The program, this means, can evaluate something like (3x/(7x-1)) + (2x/(5x+3)).

2. Automated selection of functions based on things in the expression. For example the presence of an = would lead to solving.

Here's my dilemma. I know that TI-Basic is better for floating point math. Assembly is not, so I'm not even asking about that. Axe, however, provides routines for floats. When it comes to floating point math, TI-Basic is my friend.

However, the amount of scrap that would be needed to evaluate complex polynomials is, in my opinion, beyond what TI Basic can facilitate. I would need to use vast amounts of RAM, be able to retain the position of them and what they relate to, and so forth and TI-Basic would make that very hard. So for this, Axe is better I think. So, I'm kind of torn. Either way, i'm going to have an issue with something. I guess the question is, which struggle is the least of the evils?

Art / Star Trek sprites
« on: November 11, 2013, 08:57:58 am »
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)

Axe / Axe source questions
« on: October 28, 2013, 02:25:55 pm »
The 3-layer greyscale routine used by Axe. How many times does it iterate to constitute rendering greyscale for 1 second, approximately?

TI Z80 / Star Trek... new feature ideas and setup
« on: September 26, 2013, 07:08:13 pm »
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.


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


  • 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?

TI Z80 / PROGRAM: Polynomial Math Utility
« on: December 02, 2012, 12:15:09 pm »
Works on :  TI-83+, TI-83+ SE, TI-84+, TI-84+ SE, TI-84+ emulator on the TI-Nspire.

At the bequest of an old friend of mine, I fished out my really old Synthetic Division program. I was intending to fix it up and ship it off, but when I saw the code, I realized how much of a mess it was. So I started over. This program started off as a Polynomial Division Utility, but it evolved into a suite for doing all four standard operations with polynomials. The algorithms are brand new, and optimized with help from an old high school friend.

This program can theoretically handle polynomials of infinite size, but, of course, bounded by your memory. See the speed test information at the bottom. It can also handle fractional coefficients. The input occurs in descending exponent order, where the calculator will first prompt you for the number of terms in the polynomial, so for x^3+x-1, you say '4' (without the single quotes  ;) ). You will then be prompted for the coefficients. You would input 1 for exponent 3, 0 for exponent 2, 1 for exponent 1, and -1 for exponent 0. Repeat this procedure for the second operand. Alternatively, for either operand, you may enter a value of '-1', '-2', or '-3' (without the single quotes  ;) ). '-1' loads the last Operand 1 you used, '-2' loads the last Operand 2, and '-3' loads the last result. You may supply either of these three arguments at either operand prompt without issue.

Speed Test

DISCLAIMER: This speed test was conducted on my own hardware, a TI-84+ SE, running OS 2.43. While you may experience results close to this, no two pieces of hardware are exactly alike.

for Multiplication
a 19-term times a 19-term: done in 3.35 seconds.
a 37-term times a 37-term: done in 7.52 seconds.
a 73-term times a 73-term: done in 16.94 seconds.

for Division:
a 73-term divided by a 37-term: done in 7.39 seconds.
a 37-term divided by a 19 term: done in 3.21 seconds.
a 19-term divided by a 9-term: done in 1.88 seconds.

ASM / The Z80 Files (A tutorial)
« on: June 15, 2012, 09:25:16 pm »
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.

ASM / Bit Math
« on: April 29, 2012, 12:19:12 pm »
Just wondering.... Is this the correct way to Multiply numbers, using bit shifting. Modify as needed. And how would you do division?

Code: [Select]
ld c,a
$: rl a
rr b
jr c, +$
jz nz, -$
$: or c
push af
ld a,b
or b
ret z
pop af
jr -2$
;Your next command, upon returning, should be pop af.

TI Z80 / Dev Team for Zelda
« on: April 24, 2012, 09:42:39 pm »
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.

TI Z80 / Zelda resumed and almost done...a bit of help needed
« on: April 20, 2012, 07:39:23 pm »
I have resumed my Legend of Zelda project. And, I have it mostly done, although the most daunting parts lie ahead. Any coders who have expertise in the areas I will list below and want to help me out with coding this...I would be happy.

1.  Greyscale texture sprite rendering system. Tiles are 8x8.
2.  Animated sprite rendering system (for the player and enemies). Tiles are 8x8, but should move 1 pixel at a time, and support all directions of movement, even diagonal.
3.  AI system.

Other than that, the rest of the game is fully coded ;)

Although I do want to do one more thing...RLE encode the maps. I need, thus, a compression utility that I can use on computer to compress a string of bytes, as well as a z80 routine that will decompress it. I'm sure the later is lying around on these forums somewhere.

TI Z80 / CalcRAR
« on: February 23, 2012, 09:36:57 am »
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.

TI Z80 / Harry Potter sprites
« on: January 23, 2012, 09:26:42 am »
Can anyone with some spare time on their hands make a few Harry Potter sprites. 8x8. I'd like each of the main characters of hp7, but I suppose just a Harry and then one generic will suffice. Also, is there a way, when moving a sprite to memory, to rotate it by some degree?

ASM / Chemical Formula Input Routine
« on: January 18, 2012, 02:14:40 pm »
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.

Code: [Select]
    ld  a,0
    ld  (penCol),a
    ld  (penRow),a
    ld  de,saferam1+1
    ld  a,0
    ld  (saferam1),a
    ld  a,0
    jr  z,getKloop
    cp  $01
    jr  z,switchnumeric
    cp  $04
    jr  z,switchalpha
    cp  $02
    jr  z,backspace
    cp  $09
    jr  z,done

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

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

    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

    .db 0,0,0,0,0,0,0,0,0,0
    .db "WRMH"


ASM / Interaction with a 3D Space
« on: December 02, 2011, 03:15:47 pm »
I'm looking for someone with experience in programming interaction with a 3D space for my Star Trek game. At present, I only support 6 directions of movement: up, down, left, right, forward, and backwards. This is not truly 3D. I was thinking of using a pair of x,y vector and a z vector, but I do not know how to code this. I will need someone to code this up for me.

In addition, if I go with the above, I will need to redo the routine in which we look to see if a ship is in your viewscreen. I'll need that coded, or at least assistance with that, as well.

ASM / Chemical Formula Input Routine
« on: November 04, 2011, 01:19:45 pm »
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.

ASM / Angle Calculation Help
« on: October 28, 2011, 09:41:30 pm »
Also posted on cemetech...

I had an old program that I made in TI-Basic. I have wanted to convert it into z80 for a while. It was a Lewis Structures drawing program. It several shortcomings: (1) it could not handle drawing off-screen, and (2) It could only handle formulas with one central atom, and the others around it. (NH4, for instance).

I want to redo this. In z80. Such that it can not only handle such formulas as HH4 and H2O but more complex ones as well, and shows single, double, and triple bonds. So, I'm asking the following questions:

1. How do I calculate angle degrees in z80? When drawing Lewis Structures, spare electrons must be accounted for by leaving one space. For instance, in a water molecule, you know that it is a bent molecule. Because of the electrons left unbonded on the hydrogen, the oxygen molecules are pushed to the opposite side, at 90 degree angles to each other. Understand what I'm asking? Or maybe someone who knows more about this can explain better?

2. How do I make the program able to scroll to the left or right of the display in order to show offscreen parts? Would the DCS GUI features be best for this?

Any help I could get would be great. I'd be willing to co-author the project with someone who knows how draw Lewis Structures , who could handle the technicalities of calculating and drawing.

Pages: 1 [2] 3 4 ... 7