LuxenD wrote:
Your doing this in Ti-Basic? i sure hope you include a nice sized manual on how to play this, it looks pretty complicated...
That's the current plan, until I find a really convincing reason not to. 
A manual is definitely going to be included.
Actually, the one convincing reason not to do it in Basic that crosses my mind is if I wanted networked multiplayer (and the possibility of a computer client and a calculator client that both connected to the CN2.2 hub for doing so), but at the moment I'd really like to do it in Basic to show off the graphics.
elfprince13 wrote:
the possibility of a computer client and a calculator client that both connected to the CN2.2 hub for doing so...
uhh, your going to have the calculator try and play the game with a computer?
***Brain crashes
LuxenD wrote:
elfprince13 wrote:
the possibility of a computer client and a calculator client that both connected to the CN2.2 hub for doing so...
uhh, your going to have the calculator try and play the game with a computer?
***Brain crashes
It's crossed my mind in a more than casual way. Obviously, if I were to do that, it would no longer be in BASIC.
exactly why my mind crashed when i read that.
Doing it with calcnet wouldn't be too hard,
I even made a C# library for interfacing with gCn, though I doubt you'll use it
. The code's all in there, though, if you want to use it for reference.
I'd probably rewrite it in C, so that I can maintain a single codebase for the game rules and abstract out the player, rendering, and networking code. Just need to make sure SDCC doesn't use any conventions that would clobber the CN2 routines (which I think is unlikely, since Kerm generally writes more robust code than TI does)
Ti pays a group of people to write half-codes that could be soooooo much better.
LuxenD wrote:
Ti pays a group of people to write half-codes that could be soooooo much better.
Wait--what?
compare any codes you get from Kerm (or any other good asm programmer) and Ti:
who's code is more readable?
who's code is much more optimised?
The beginnings of an experiment. What is this craziness?
Also, more theory crafting. Any thoughts are welcome.
Quote:
I think I have a solution to balancing the single hatch/aggressive creeping mechanics we discussed. Zerg receives 1 resource from a hex for every 2 edges covered by creep, and a multiplicative factor of 1/2/3 for Hatch/Lair/Hive. *BUT* any creep that can be cut off by enemy building placement dies. To counteract this, the Zerg can build Nydus Worms to produce new centers of creep, *BUT* the Nydus
worms are hungry and decrease production by 1.
Only production structures are subject to 2-edge spacing rules, so Pylons, and Nydus Worms can come within 1 edge of another structure on a vertex.
The cheap hatch upgrade is replaced with an upgrade to allow nydus worms to burrow into totally-uncreeped regions of the map and start new networks.
I really like what I see there, Elfprince! I only hope the optimization is good enough to fit your code in under 8KB.
Me too. I think I have some creative solutions to pull it off though, if the situation is dire.
elfprince13 wrote:
Me too. I think I have some creative solutions to pull it off though, if the situation is dire.
Good stuff, I can only imagine. Will you be dealing with any of the issues from this LLVM topic?
At the moment I'm planning on only having access to sdcc. Depending on how the llvm stuff goes, I might switch. We'll see.
Double post....but I'm proud of this!
[edit]
compare with:
That looks awesome! What are you going to be doing to cram that grayscale image in there? What display library will you use?
I typically use the RIG routines to display stuff in grayscale. I can always remove it if I'm crammed for space, but the routines themselves aren't too big, and the linker for SDCC is smart enough to punt static data to the end.
elfprince13 wrote:
I typically use the RIG routines to display stuff in grayscale. I can always remove it if I'm crammed for space, but the routines themselves aren't too big, and the linker for SDCC is smart enough to punt static data to the end.
Excellent; that's exactly what you'll need. I'm still very excited to see if the LLVM project will yield optimized z80 ASM, just in time for color games on the TI-84+CSE. If Cemetech could lead the way in C games for the device, it would be amazing.
HMMMM. What is this trickery?
[edit]
Also, the SDCC linker seems to have gotten confused as I've added additional files to the project and seems to only separate code and data within each object file, but not in the final project. I'm not sure if this is a fundamental limitation, or if I just need to use trickier command line flags.
nice idea with the splash, great graphics. though i wonder: how did you make this into grayscale?
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
