An Axe question: For Base 671 (among many other project ideas) I'm really wanting to get into implementing multiplayer support through the link port. What techniques and routines are out there for link-play?
I've spent the last four or five days screwing around with Zedd Physics Library, and I have to say, I really really really like it. It's SO EASY! What I've made so far, in less than a week, would normally have taken months, literally, and it still wouldn't have worked right.
It took me exactly two days to figure out how to configure tilemaps, write a good tilemap masking program, and add objects. Oh yeah, and in a blatant Graviter-rip off move, I added gravity switching.
So I got bored with that, so I figure out ropes, moving platforms, and a full buoyancy simulation, with a pool of water on the bottom here. Two more days work:
And then I got bored in physics class earlier today, so I made this 3d looking thing that's kinda dumb but whatever, I'll post it anyways.
Yep, there ya go. PM me if you want the executables or the source.
Btw, Builderboy or leafiness0, I want to significantly decrease the elasticity. How would I go about that?
I made this thread so that I could ask Builderboy specific questions pertaining to the completion of Portal X.
First question:
Would you happen to know off the top of your head what {L1+700} does? It's not labeled in the variable list. Also, what's the state if the level exit transition code?
Hey, so, in the interest of all Axe programmers who want to squeeze as much out of their calculator as possible, I think we should start a contest of sorts, to see who can make a given chunk of code as small as possible.
The way it'll work will be like this: Someone posts a chunk of Axe Parser source code that they want to have optimized. It must not be longer than about 50 lines, but 60 is the absolute max. Then, everyone will post how they would optimize it. When you post how you would optimize the code, post your source, with code tags, and post the size of the compiled executable file, in bytes. That's important. We're not optimizing to get the smallest source code, we're optimizing to get the smallest executable. Thus, optimizing out comments will help you nothing, if you're looking to win.
The winner of any given competition gets serious bragging rights, and I'm sure also more respect and lots of +1s for his post.
Important Points: > We're trying to get the smallest possible executable. We don't really care how bloated the source code is, with comments and whatever else. > Optimize for size, not for speed. Size optimizations can be much more accurately measured and calculated than speed optimizations.
Compiled Size: 358 bytes Compiled for No Shell, using Runer's bugfixed version of 1.0.3 You can compile for any shell you want, and using whatever version of Axe you want, whatever's smallest.
Optimize, GOGOGO! Remember, retain all the functionality of this current program. Add no features, take away no features. Simply optimize the living crap out of this thing.
Hi everyone. For PaintPad, I'm really close to releasing the first version, but before I do, I need a flood fill algorithm. I've tried a little bit, but haven't been able to get anything to work. So, I'm making it a contest of sorts.
I'm uploading a very, very, very watered down version of PaintPad, all it supports is pixel drawing and deletion. All I need is a simple flood fill function - the template is there, all that it needs is the code.
So yeah. If you're up to it, check it out, and upload or post the code for your floodfill function.
Also, here's the code for anyone not wanting to go to the trouble of downloading an sending the attached source file, FLOODSRC.
.FLOOD .The challenge is to write a good,solid floodfill function.
DiagnosticOff
.Cursor coordinates 10->X->Y
.Start the program with the cursor at 10,10
.The arrow keysmove the cursor
.When you pressALPHA, call the flood fill function .When you press2ND,it draws a pixel at the X,Yposition
ClrDraw ClrDraw^^r
.Clear exits Repeat getKey(15) .This code is unoptimized,and I use a lot of functions, for clarity purposes Input() .^All this function does is getinput from the arrow keys .Now,to get input from 2ND and ALPHA .Remember- .2ND=Draw pixel .ALPHA=Flood fill .And [DEL] deletes pixels If getKey(54) Pxl-On(X,Y)^^r End If getKey(56) Pxl-Off(X,Y)^^r End .Now,its your turn to write some code. .All I need is someone to writethe Flood() function. If getKey(48) Flood() .^That. .Scroll down tosee what code needs to be written. End .Now,for some boring display stuff .Everything is stored on the back buffer .The front buffer is for displaying the cursor and other stuff RecallPic .Display cursor Cursr() DispGraph Pause 75 .End of main loop End Return
.Finally,the flood fill function! Lbl Flood
.YOUR .CODE .HERE
.Remember, dontwrite to the front buffer,usethe back buffer
Return
.Other functions
Lbl Input If getKey(1) and (Y<63 Y++ End If getKey(2) and (X>0 X-- End If getKey(3) and (X<95 X++ End If getKey(4) and (Y>0 Y-- End Return
Lbl Cursr
Rect(X,0,1,63 Rect(0,Y,95,1 Pxl-Off(X,Y
Return
Eh, spacing on the comments is a little weird^^
PS for anyone who doesn't know what I mean by "flood fill function", it's pretty much the bucket tool in mspaint.
So, I have this idea. I'm not making it into a game (yet ) because I have other stuff to do, but I probably will in a few months or so, when I can get around to making the time.
I like RPGs, but I feel like they lack something. And I like Platformers, but I feel like they lack something. So I want to make a combination of the two! I'll use Zedd and Axe Parser and any other libraries or whatever else I'll need. I kind of have a basic roadmap in my mind for what this will be like: pretty much, you have to go through several worlds, like probably about five. Each of these worlds will have five to ten levels. And for each world, the focus is different. Like in World 1, you push blocks around, like a better physics version of Block Dude. In world 2, it's some kind of Shift/Spacky 2 type game, or like Darl's Dimension Shift.In world 3, it might be some kind of a gravity-switching world. In world 4, it'll probably be some kind of heavily action-oriented world with lots of different guns and/or vehicles, and lots of really smart enemies and stuff like that. And then I'll add any other worlds I feel like, or that sound cool, like maybe some form of Pocket Bomberman (GBC) or something like that.
But the thing is: in the last world, it combines and brings together all the skills you got from beating all the other worlds. So World 1 will start out really easy, and then the very last level of the last world is SUPER INSANELY HARD. So yeah. That's my idea.
Darl181, and leafiness0 - I really do not want to rip off your guys ideas for your games (Graviter, Essence, DS, etc) so I want you to know anything I make will be very substantially different than your guys's implementation of the same/similar concept.
Hi there everyone. I'm working on a project right now, Base 671, in Axe, that will eventually run as an App, because it's gotten too big. I was using CrabCake so it would run at all, and the executable was nearing 1100 bytes, which is about how big all the billions of source files put together are, so I was running out of memory, so now it's going to be an app.
What do I need to change from a nostub ASM program when recompiling as an App? I know enough not to try and use SMC, but I'm not sure what all that entails. Could someone please provide me with a list of what I need to change/prevent from happening in an App's source code?
A blog I recently started to post some of my random projects. Here I'll post some of my calc games and progs and whatever else. Currently I posted about my newest project/mostly an idea at this point, making a computer out of an Arduino Uno microcontroller.
Hey, I've been thinking about this and the more I think about it, the more I think I can actually do this. My idea is basically this: Make a functional computer out of an Arduino Uno microcontroller.
My only goal for this computer is the ability to edit and execute BASIC programs. That's all. I only want it for the programming, as that's just about the only thing I'm interested in right now
So the way I see it, I'll need three main hardware components: 1) some form of a display (VGA screen or something), 2) some way to register keyboard input, and 3) some way to store data to external memory. Does anyone know of any way to do this? I know of ways to display to a screen, but I don't know a good API/hardware component to register keyboard input or to store external memory.
I'm going to need a lot of help on this. Can anyone help me out and offer ideas and useful tips and suggestions for good hardware / a good open source library, or two, or three, or ten?
Hi everyone. My current project right now is a game I'm calling Base 671. Basically, the story goes like this: It is the year 2150, and you are a well trained and armed battle hardened space marine. The last battle in which you fought went horribly wrong, ending with more than half of your forces dead, and all survivors captured. These survivors, including yourself, were brought to an awful place, a space station known as Base 671. This base is infamous for epic gladiator style arena fighting. Well, lucky you, you have been selected as the first contestant in these fights. You, in a provided combat pod, are forced to fight your way through wave after wave of enemy lines. It is up to you to defeat all of the enemies that come your way, and by so doing, saving the rest of your forces from a horrible. After all, they couldn't stand for three seconds in this arena.
Base 671 ----- 15% completed
Official Description: Futuristic Deathmatch Arena Style Futuristic Shoot-em-up game written in Axe Parser for the TI-83+ series. This game is a loose port of the Flash game Pixel Purge.
Currently implemented:
Rotational Movement Engine Weapons: Flamethrower Enemies: Four different kinds, but right now they all do the same thing, just look different Scrolling Grayscale Background Character Explosions
To be implemented:
Items (health, ammo, regeneration) More Weapons Machine Gun Hand-to-Hand Weapon (Sword or Whip) Cannon Explosive Laser ...Any other ideas? Heads Up Display Enemy Explosions and Pixel Collection Level Up Screen and effects Bosses (Super l33t! Not lame!) Some kind of a Store (to buy upgrades and new weapons and things like that)
Controls:
Left and Right to change direction 2nd to accelerate Alpha to accelerate backwards Mode to shoot
Any and all feedback would be appreciated! Let me know if you have any fabulous ideas. Post them here, or PM me.
Oh yeah, screenie:
EDIT: In the screenie, I barely showed the flamethrower at all. Download it and check it out if you want to see more
I, as hopefully a great many others who are on this site, have a great deal of love for programming. I got into programming at a time in my life when I was very lonely/bored out of my mind/etc. I really feel like other people need to give programming a try, and embrace the nerdiness. Who cares what other people think?
Anways, I created this thread to discuss how to "convert" people to programming, specifically programming calculators (inspired by the "Why Johnny Can't Code" thread, found here: http://ourl.ca/13080).
I like to think I converted Parser Padwan, first to TI-BASIC and taught him the basics (yuk yuk yuk) of it in math class. Any conversion stories you'd like to share? What works? Parser Padwan, would you mind telling your side of the story (about your "conversion") ?
As some of you might know, I've been working on a platform game called 'Fantastic Sam'.
Enough talk. Screenie:
I won't write too much here. Everything is explained in the Important Readme.txt, which is pretty darn good if I do say so myself (the readme is good, and what I was referring to. )
For a project I'm working on / thinking about (one of three ), I made a physics based acceleration/gravity movement engine, inspired by reading through BuilderBoy's physics lessons. I've thought through the game, and the one element I'm having trouble with is working on the collisions.
I can't think of a good way to handle collisions while also avoiding two things: stopping in mid-air above a block, and accelerating right through an object. I would prefer some method based on pixel-test or something like that, but a regular tile map based collision would be fine.
Show Posts
) because I have other stuff to do, but I probably will in a few months or so, when I can get around to making the time.
), I made a physics based acceleration/gravity movement engine, inspired by reading through BuilderBoy's physics lessons. I've thought through the game, and the one element I'm having trouble with is working on the collisions.