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.
Messages - thepenguin77
Pages: 1 ... 12 13 [14] 15 16 ... 108
196
« on: November 04, 2012, 11:33:42 pm »
I once made a chess AI on my PC but I doubt it will be possible with Axe on calculators
The calcs are to slow and they haven't enougth memory
It's <a href=http://ourl.ca/9904>already been done</a> in ASM with grayscale graphics. I don't see why it couldn't be done in Axe. 
Woah now. If we're going to link him, at least get him the most recent version.
197
« on: November 04, 2012, 07:18:20 pm »
Try this: http://www.ticalc.org/archives/files/fileinfo/268/26877.html
It's a really great tutorial and walks you through step-by-step. You can also access it online at http://eeems.omnimaga.org/files/Resources/Tutorials/ASMin28Days/lesson/toc.html.
It recommends TASM but I personally prefer Spasm, which was designed for the TI-83 Plus series. Some syntax may be different from that of TASM, however. (Or if you prefer online tools you can try my own ORG IDE  )
I completely agree. I learned with 28 days (and still reference it from time to time) and currently use spasm as my assembler. If you also decide to go with this setup, this is what needs to go in your asm.bat file that you make on the first day. This is because spasm has a different command line syntax than tasm: @echo off
copy c:\asm\source\%1.z80 %1.z80 > nul
spasm %1.z80 c:\asm\exec\%1.8xp
del %1.z80 > nul
time /T
Don't worry about that "time /T", that will help you keep your sanity later on. (Actually, don't worry about what any of it means, this is one of the hardest steps in learning to program for the 83/84.)
198
« on: November 04, 2012, 07:10:48 pm »
I searched for Geometry Wars on Ti-Calc, and found the one of thepenguin77. Then I downloaded it and ...
Only for 84+, sorry. Tehe Anyways, since you have 1/3 of the power, you're probably going to have to use 1/3 of the calculations. After my later updates (with super optimizing and partitioning) geometry wars started to lag at about 70 enemies (especially 70 dodging enemies). I usually estimate that while playing geometry wars, there are about 30 bullets on screen at any one time. This means 2,100 bullet-enemy collision checks per frame. I also ran the game at 30 fps. So I was pulling off a massive 63,000 bullet-enemy collision checks per frame. This means you should shoot for about 20,000 checks per frame (assuming you can match my detection speed  ) Since I've already thought about this, here's what it looks like to decrease each variable: - Enemies - this one is straight forward, take out enemies (at the cost of an easier game)
- Bullets - you can either decrease the rate of fire (which will make people hate you), or make the map smaller so they hit the edges quicker
- FPS - You're probably thinking that 30fps is really fast, but I'll tell you that the game needed that. When I used 15 fps, bullets would often travel right through enemies. This meant that if you tried to bulldoze the enemies, typically, one of the little squares would squeak past and kill you.
My suggestion would be to use a smaller map with more enemies and keep a high fps. This I believe would lead to the highest quality of gameplay on an 83+. But, good luck
199
« on: November 02, 2012, 02:01:14 pm »
Ok, I'm sorry, but what the hell are you talking about? Unsigned: patches 1.03 bootcode so you can downgrade your os.
It doesn't patch the boot code, it patches the certificate (and can, in principle, brick your calc if you pull the batteries at the wrong time.) (But I don't blame you for not knowing the specifics of the patch) the author of Epicfail, an alternative to unsigned, says that if it breaks your calc, you will not be able to return it because you have modified it.
I don't know whether he actually said that somewhere, but I know brandonW is the kind of person who would completely trash a calculator for testing purposes and return it to Walmart, so I doubt he would say that. The maker of unsigned says you will be able to return it if unsigned breaks your calc. Something to keep in mind if you're deciding between the two.
I wrote it, never said that (though in both cases, your circumstances are the same, so whether you can return it or not is irrelevant between the two. If you take your calculator to Walmart and say it doesn't work (after recently buying it) they are just going go say "hur dur" and let you get a new one) Edit: In the end, here's how it works. You have about a 30 day window to return your calculator back to wherever you bought it. So if you break it during that period, you're good. But after that, you're not going to be able to take it back no matter what you do. It's the same thing with all other appliances, if something mysteriously stops working within 30 days (and the store can't tell that you actually broke it), you can take it back (not technically legal, but meh). After that, you're just out of luck.
200
« on: October 28, 2012, 10:08:46 pm »
SO I patched with unsigned, awesome program. Now I need a program that can archive all my programs (a program, not an app), this is a workaround for Brandonw's program with his fake reset prog. Does anyone know of such a program?
zStart does it (my signature). Press ON + VARS at the homescreen and it will archive all of your programs.
201
« on: October 28, 2012, 05:00:15 pm »
I will not degrade, epic fail does have a chance of breaking my calc Have there been reports of that yet? Just tried it yesterday and it worked great
I'm going to assume brandon did all of his usual redundancies on this one (like MD5 hashing the boot code to make sure it's the right one) so the way I look at it is this: During the operation of epic fail, there is a chance that it could brick your calculator. The key word here is chance. Normally, it is impossible to brick your calculator, but when running epic fail, the window is open. How likely is it? To brick your calculator, a crash would have to occur that overwrites the boot code in a way that makes it crash. A good thing to compare this to is accidental OS modification, how often does this happen? I don't know any good numbers on this, but I'd chance a guess at 1 time per year for us calculator programmers. Assuming we do on average 20 different calculator activities per day (every day) that puts an OS modification event at 1 in 7,300 calculator activities. How likely is a modification to cause a crash? I'm pretty good at asm, so I'll say 1 in 4. This means there's a 1 in 29,200 chance that a calculator activity is going to cause your OS to crash. The OS is comprised of 22 pages (23 if we include the boot code). So now that we can figure the boot code into the equation, there is a 1 in 23 chance that this fatal error will happen in the boot code for 1 in 671,600. But hold your horses, only about 1/4 of the boot code actually gets run (in a bricking situation), throwing away all decimals, this puts you at about a 1 in 2,000,000 chance of bricking your calculator. The key here is like I said earlier, normally, you can't brick your calculator, but when you run this, there's a 1 in 2,000,000 chance that you will, and brandon doesn't want to get sued.
202
« on: October 28, 2012, 01:19:14 pm »
I will not degrade, epic fail does have a chance of breaking my calc
*cough*(Mine always gets left in the shadows....)
203
« on: October 25, 2012, 06:43:26 pm »
This isn't very on-topic, but if besides reading data from archive you also plan to write to it, be very careful to not mess up and writing to the wrong Flash sector (OS certificate). This can permanently damage your calc. Not sure if reading the archive directly from the wrong sector can cause damage, though.
Reading from flash and writing to flash are very very different. Reading is super simple and the flash just acts like ram. Flash is constantly being read when the calculator is turned on and the OS functions by simply running from flash. In order to actually write to flash, you have to first unlock flash and then use some very specific bcalls to write data. On top of that, to mess with the certificate, you have to accidentally write to page 7Eh which if you are going to randomly write to a page, is only a 1/256 chance. (I said "flash" way to many times, but I don't think I can avoid that) So yes, thanks for the warning, but no, that can't possible happen.
204
« on: October 25, 2012, 01:44:48 pm »
Of course CPU is a problem 
 Man, that would suck to have to make a chess AI on a 180MHz ARM processor with native grayscale... (Btw, as for how good was my AI, SirCmpwn told me that he lost every single game he ever played. And it will beat me every now and then if I make a mistake)
205
« on: October 24, 2012, 02:54:48 pm »
I'm going to assume I found a glitch. (Unless you want to use this to make really sneaky levels)
206
« on: October 23, 2012, 05:28:19 pm »
Speed is simply how fast you want your bullets to move. 8 would be 8 pixels per frame, 1 would be 1 pixel per frame, and 96 would be 96 pixels per frame. (Assuming the units on xVel are pixels/frame of course)
You can set it to whatever you want.
207
« on: October 23, 2012, 01:20:25 pm »
Edit5 was exactly what I was going to point out about your routine. But I'm glad you got it working.
Btw, for an update like this, you can totally double post. I do it all the time.
208
« on: October 23, 2012, 01:15:22 pm »
I'm trying to put together a routine that will calculate the appropriate X/Y velocity to go towards an object. What i've got now is really buggy, i think the general algorithm/idea is ok though. My biggest hurdle so far has been handling negative numbers, as none of my routines for multiplication/division seem to like negative numbers. What i'm currently doing is really just adjusting the Y velocity and not bothering with the X velocity. The general equation is something like this:
(object Y - bullet Y)/(object X - bullet X)
The X/Y velocities have 5 bits which act as a decimal place, but this doesn't let me use it. I hacked in the ability to handle negative numbers in the division routine (essentially turning all negative numbers positive, then negating the result afterward), but my multiplication routine doesn't like negatives numbers either.
Ok, so basically, I'm assuming this is what you want to happen: Angle = atan2(x, y) xVel = cos(angle) yVel = sin(angle) Now, yes, this will work, but it's not going to be very fast. Atan2 is just arcTangent that will give you the angle even if it's in the [90,270] region, but that thing is a little annoying to implement. Cos and Sin aren't that hard, but require lookup tables. Before I explain this, to make things easier, dX = object X - bullet X and dY = object Y - bullet Y. What I recommend you do is treat this as a vector problem (sorry, I'm currently in calc 3). Basically, you have your direction vector <dX, dY>. So there is no need to recalculate the direction. All you need to do is scale it to the right speed. So, the way to do this is to first find the length of the direction vector : length = sqrt(dX^2 + dY^2). And then to scale it to the right speed, divide by the length and multiply by the new speed: <dX, dY>/length*speed. In the end, here's what you get: length = sqrt(dX^2 + dY^2) xVel = (objectX - bulletX)/length*speed yVel = (objectY - bulletY)/length*speed The only tricky part of this routine is the square root, but I know I've seen a few around here, so that shouldn't be too difficult.
209
« on: October 20, 2012, 01:28:10 pm »
I agree with DJ on mibbit. It's the one I use. It requires no installation and you don't have to use the /server command. https://cbe001.chat.mibbit.com/
210
« on: October 16, 2012, 05:36:09 pm »
The next page is simply the next page. Literally. So if you run off of 08, the next page is 09. You never have to worry about it crossing a sector (i.e. 0B -> 0C or 0F -> 10) because TI's file structure doesn't allow it. One problem I immediately see with your code is that it assumes that the name of the program is going to be exactly 4 letters long, if that's true, then cool, but otherwise you'll have to add some code to fix that. Here is a relevant wikiTI article on the flash variable format, what you're interested in starts at "After the status byte for that sector..." Anyways, the best way to check if you went over $7FFF is to check bit 7 of h. If bit 7 is set, then increase the page number by one, reset bit 7, and set bit 6. Here is how I've been doing this whole process for the past 3 years: (this is from zStart)
ld hl, name
rst 20h
bcall(_chkFindSym)
call findStartInRom
...
;##################################
;Move to start of data in Rom
;Input: Output of _ChkFindSym
;Output: HL = start
; B = rom page
;Destroys: C DE
FindStartInRom:
ex de, hl
LD de, 9
add hl, de
call fast_bhl
bcall(_LoadCIndPaged) ; number of letters in variable name
inc c
ld e, c
add hl, de
;$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;fall through
;########################################
;faster bhl
;only checks for going over
fast_bhl:
ld a, h
res 7, h
set 6, h ; this is a little hacky to save space, but it does what I said it does
cp h
ret z
inc b
ret
Also, if speed isn't an issue, there's always bcall(_flashToRam) (it's not actually all that slow).
Pages: 1 ... 12 13 [14] 15 16 ... 108
|
Show Posts