You must Register, be logged in and have at least 40 posts to use this shout-box! If it still doesn't show up afterward, it might be that OmnomIRC is disabled for your group or under maintenance.
Note: You can also use an IRC client like mIRC, X-Chat or Mibbit to connect to an EFnet server and #omnimaga.
the size change of the player sprite is something what I thought about too. It wouldn't be hard, I might need some nicer sprites though. The path isn't centered because I wanted to show the score and stuff on the right. I could center it, but it slows down the game a lot when you don't cut the sides. So I thought it might be better to have more space on one side instead of only little space on both. I might change that though.
A game which was requested a lot lately. I've seen some attempts on making it in 3D, but I figured it could be done in 2D to simplify things a lot.
Here is what I got working at the moment:
Running on a randomly generating temple
Corners, junctions, damaged parts and gaps
Steering and jumping (could need some aesthetics)
Speed increase
Collisions
Score display (not activated yet)
Planned features:
Collecting Coins
Power-ups
The monkeys / a giant ball (Indiana Jones style!) behind the player
High score table and menu
I probably won't add other "terrains" and obstacles, because the result in looks wouldn't justify the efforts. Also I'm not a big fan of the "shop" so I think I'll leave that probably out too (for now!).
You hold the calc across with the keypad on the right, so you can benefit of the high size / portrait screen. You play either with the arrow keys (up/down: steer; right: jump) or with the respective keys on the num pad (7/8: steer left; 5/6: jump; 1/2: steer left). Holding the keys will make the guy move to the sides (like tilting the device on the original game) and klicking short at the corners will make the guy turn (like swiping on the screen in the original game).
Feel free to try out the game, criticize and suggest features. It is still in an early stage, this is the first playable version.
I found another bug with Axe compilation. Unlike Axe, zStart doesn't check whether a program is compilable or not, so you can accidentally compile another source file (e. g. a file with subroutines etc.) which is not meant to be compiled as the main program by Axe. It causes Axe to crash or compile another program (like the one directly above or below (?) in the program list). Of course you can avoid this by not doing the On + Sto-> in the wrong place but it happened multiple times when I didn't watch out.
Address->°Name will create a custom variable called “Name" at the given address. You can call the varables how you want, in this case CosLUT or SinLUT. The address should be some empty ram area at least 2 bytes large, since the varables in axe are all 16 bit - at that address the value of the variable is stored. Once you created a new variable, you can use them just like any other variable A-Z or theta. In the second step you make those variables point to some free ram (L1 and L1+256), so now they hold the the address of the both areas which are use as LUTs.
Some time ago, I made my own raycaster, however I halted the project... I need to finish it some day
Yours looks awesome so far Looking at your code, I realized that it is quite slow. You only draw 1/4 segments of the screen, and it is running at 15 Mhz. I'm not an expert at raycasting, but I think you need to restructure parts of the code to really optimize it. Still, here are some minor optimization tricks you could use (but I don't think they really matter that much):
Using a sprite is a cool idea to store the map, but the pixel-test function is incredible slow (and you're doing that a lot each frame!). Try directly accessing the data, e.g. in an 2d array/matrix etc.
The next optimization helps almost everywhere: If size doesn't matter, use a bunch of /2 instead of dividing by a power of 2. For example: A/2/2/2 is faster than /8 This trick works due to the fact that /2 is replaced by a shift operation, whereas every other division calls a routine to divide (which is kinda slow)
Lbl TV abs(V-X)*128//cos(r1)*sin(r1)//128→U Return
This code looks slow because of signed division and trigonometry. These functions are also called a lot each frame!
Also, if you need a function only once in the code, you can type it inline where you need it to save some bytes and cycles without the call. If you want to keep readability, you can include them in another program. Also, what helps reading the code is the C++ style function calling syntax: Function(arguments) instead of sub(Function,arguments) For example:
I came across this "bug" multiple times now: When you turn off the calculator while you're editing an archived program (the copy of one), and zStart wants to store the edited version and GarbageCollect appears, the LCD turns off and and it doesn't react on any key presses (calc behaves like turned off, but it isn't) before you can do a GarbageCollect. You need to remove the batteries and lose the current progress which is kinda annoying Is there someway you can prevent the calc (or its peripherals) from turning off when the program isn't saved yet?
That's my piano roll music editor and player I made a while ago. It uses the Freq() function of axe, so the quality is pretty bad but it works quite well though.
The all examples with the accelerometer use the same program on the PIC, the programs on the calc are independent and made in axe. The Pic pretty much listens for a request by the TI (when data pin is set to HIGH) and makes a analog to digital conversion of the analog X and the Y values of the ADXL. Those raw values are sent as two bytes to the calc. The calculator subtracts a calibration value (stored at program start) off those bytes, so you get 0 when the board is hold horizontally. The new values function as the speed of the cursor. But it is indeed a nice idea to write a hook and control the OS with the board.
You didn’t hear much from me for a while now, but don’t worry, I’m not gone. I just hadn’t a lot of time because of school. But that doesn’t mean I have nothing for you to show - especially for my b100000000th post
About half a year ago I came across the PIC microcontrollers by Microchip and since I was making a bunch of asm routines at that time, I decided to give them a try. I hooked up the PICkit3 demo board to my 83+ and programmed some routines for serial communication. With the accelerometer ADXL-335z at the AD inputs of the PIC it is even possible to control programs by moving the breadboard around. As power supply I’m using a Nokia BL-5C battery which lasts quite long (1020 mAh) and is relatively light in weight.
; GET() ; gets a byte from the port as a sequence of 0s and 1s on the ring ; (bit 1 of port 00h) on falling edge of the tip (bit 0 of port 00h) ; the sequence begins with least significant bit.
; (1) Read tip ; (2) Repeat (1) until tip low ; (3) Read ring ; (4) Put that at bit 0 of result ; (5) Rotate result right ; (6) Wait until tip back high ; (7) Repeat from (1) total 8 times
ld bc,$0803 ld hl,$0000 loop: in a,(00h) bit 0,a jrnz,loop andc sraa add a,l rrca ld l,a wait: in a,(00h) bit 0,a jrz,wait djnz loop
Interrupts have to be disabled.
In later versions I used polling to keep sender and receiver in sync, but the delays between the bytes are fixed. Thus, there mustn't be too much code between each GET(). It works quite well for now, but the program might get stuck in more complicated applications. To prevent that, I'm planning to make a closed function for the whole communication process.
This project isn't finished, I showing just early prototypes.
Planned features:
General purpose functions for axe and pic programmers
Because GBD1 is in the program code, all your commands will be part of the memory. You have to put the []->GBD1 after the GetCalc, otherwise your data starts with "Getcalc" instead of that chunk of Hex!
Show Posts
Thanks for posting
I need to finish it some day
