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 ... 54 55 [56] 57 58 ... 108
826
« on: June 17, 2011, 01:00:48 am »
On my calculator, $1F is the only command that makes the blue screen of death occur. Just slightly different drivers. The port 20h thing is caused by the OS like calc84 said. But actually it's caused by the OS executing hooks. I just looked at the code, and what the OS does, is when running the hooks, it sets the calculator in 6MHz mode. Then when the hook is done, it takes out the old port ($20) value and and's it with 1. That would be why it appears you can't set it to 3. To prove my point. Turn your calculator off. Hold Left+Right and press on. Press clear. That just disabled all hooks. Now try it again in calcsys. You'll notice that you can now set 3. And DrDnar. 120 FPS is the slowest the LCD drivers ever run. During my testing, I've seen K-Factor calculators hit 280 fps running >17MHz. Edit: The desolate guy? http://ourl.ca/9538/182589
827
« on: June 16, 2011, 09:41:09 pm »
It would probably be easier to just completely reimplement Omnicalc. That's what I did when I didn't want to include Calcutil.
Although, I've found that if you leave 2.55 on Classic mode, Omnicalc doesn't really have that many problems. (I've been using 2.53 and Omnicalc for over a year now, and I haven't really had any trouble after using Classic mode)
828
« on: June 16, 2011, 05:39:51 pm »
You might want to consider keeping DoorsCS7. I'm sure zStart-Doors compatibility is somewhere on thepenguin's to-do list, and without DoorsCS7, you lose the benefits of CALCnet and gCn.
Doors compatibility is out of my hands. There is nothing I can do to make it more compatible with Doors. The only way that I could make it work is if Kerm added an entry point for me so that I can install the hooks and such just like Quigibo did for Axe. His hook managment doesn't work right either. I just downloaded the most recent version and he still hasn't fixed the chaining problems. Also, he sets up his on OFFSCRPT whether he uses it or not. Maybe I should bug him about it again.
829
« on: June 15, 2011, 08:27:00 pm »
I guess I technically could make the calculator wait for 10 seconds after turning off to show the picture, but that's how you show people your cool picture  . When I turn it on, I usually just press ON twice, it works. Ok, so that bug of yours, that's not really a bug as much as I would guess calcutil does not set up a normal edit buffer. But I don't know, so I'll look into it. But that one wasn't my fault  SquidgetX, that's caused either you tried to run the program rather than compile it, or you tried to compile something that is not an axe source.
830
« on: June 15, 2011, 06:20:13 pm »
Program editor update!!!!!!- You can edit archived programs. (Makes a temporary ram copy while editing)
- ON + VARS in program editor - Opens a list of all Lbls so you can jump to one. Also auto-completes.
- ON + PRGM in program editor - copies the current line to the clipboard
- ON + Enter in program editor - pastes the line in the clipboard
- Added option to change whether or not you want axe to auto backup, (Quigibo says he supports it, but right now he doesn't)
- Added option to remove port ($2E) delay which makes things running from flash go 14% faster
- Readme!!!
- Other little stuff that I can't remember
Editting archived programs works very well. The best part is, that since you are only editing a copy, you can clear your ram while editing and not lose your program. Also, for the temporary copy, I changed the last byte of the name so that I know it's a temporary copy. The copy and paste has a 4000 byte limit on it. This is simply because I ran out of room. But you should not need more than 4000 bytes unless you are trying to crash it. (Which you can't) For the port $2E thing, TI adds in 1 t-state per flash read and 1 t-state per ram write when the calculator is running in 15MHz mode. I tried removing it and there was not problem. So I ran a grueling test on it, again, no problem. So enable this to make stuff run faster. On a side note, this is getting pretty close to 16kb. I fear I may have to cross the boundary soon. Of course, before I do, I'm going to go back through and optimize everything as much as possible. But that probably won't take off more than 1kb. (That Lbl menu took up about 1kb) So here is zStart with a readme and source, as well as my memory test program. You can run it if you want, just to make sure I know what I'm doing.
831
« on: June 15, 2011, 01:33:41 pm »
That was exacty the question I had before I started a recent venture. It is in C. You could almost image that the cursor is a normal computer cursor, and that it is in front of the byte you are currently on. That makes sense anyways because insert mode puts the character before the character you are currently on.
This means, editCursor is always pointing to nothing. (Unless of course you're out of space)
832
« on: June 15, 2011, 12:39:37 pm »
Yes there is. Firstly, you are going to want this. This was a guide released by TI when they actually liked us. I could copy and paste the example out of editbuf.pdf. But I feel it would be more beneficial if you saw it in it's original format. Also, the edit buffer is not set up like you would expect it to be, so here is my guide to someone else. When the calculator puts info into an edit buffer, it splits the data up into two sections: What is in front of the cursor, and what is behind the cursor. These two sections are stored at either end of the free ram. Edit buffer:
a b c
|----------|------------------------------|-----|
1 2 3 4
1 - EditTop 2 - EditCursor 3 - EditTail 4 - EditBtm a - Before the cursor b - unused data c - under and after the cursor So the data: ABCDEFGHIJK|L|MNOPQRSTUVWXYZ, would look like this: (|| is cursor) |ABCDEFGHIJK|---------------------------------|LMNOPQRSTUVWXYZ|
Edited for clarity about what happens to the byte under the cursor.
833
« on: June 14, 2011, 02:29:53 pm »
You can only check between the upper and lower points if in the virtual world, from where you are standing, they are one above another. But imagine you are standing at the bottom corner of a wall looking at the other corner of a wall. Now the points probably won't even be on the same X value. Although in reality, that formula is not about finding how tall the wall is, it's about figuring out what the scale factor you need to multiply your texture by.
And textures, I think this is where the misunderstanding is. If you simply draw a bounding box on the screen and fill it with a texture, yes, the wall will have a texture. But the texture won't change when the wall does. You could stand 2 feet from the wall, or 200 feet from the wall, and the texture would always be the same size. If the texture was a brick wall, at 200 feet away, the entire wall might just be a single brick. You have to scale the texture down so that as the wall gets smaller, the texture does too.
This same thing applies if you are looking at the wall from a weird angle, if you are doing what I said earlier, looking from the bottom corner to the top corner, obviously, the bricks closer to you will be bigger than the bricks farther away from you, and for this you need texture scaling.
Here is a simple game I made a while back using this concept. You can see that the wall gets closer, you have to scale the sprite up, otherwise, it wouldn't appear to get any closer.
834
« on: June 14, 2011, 01:55:25 pm »
Ok, you can use this page and this page for pictures. What you are trying to do is to figure out how tall the wall should be on the actual screen. The concept we are using here is that an object that is twice as far from you will look half the size. So we can see that the equation would be size = k/distance. Now the question is of course, what is k. K is the distance to the projection screen. The way you calculate this, you can see in that first link I gave you. It is (screenWidth / 2) / tan(fieldOfView / 2). So assuming you are using a 60 degree field of view on the calculator. 48/tan(30) = 83. Now go to the second link. What this means, is that a wall on screen that is 83 units away, will be it's actual size. 166 units away it will be half its size, 41.5 units away it will be double size. So the formula is now (relative size) = 83/distance. Which means if your sprite is supposed to be 50 pixels tall, when it is 120 units away, it will be 83/120 * 50 = 34.5 pixels tall.
835
« on: June 14, 2011, 11:09:41 am »
Ok, here is my method. I'm literally making it up as I write this post, but in the end it should work. For this you should use triangles.
1. Convert the 3 corners to xy coordinates.
2. Calculate the relative size of the leftmost point. (3d window distance thing / distance)
3. Now calculate the relative size of each of the other two points and subtract the original from them.
4. (This is where it gets sketchy) You need to figure out the two slopes of (relative distance) / x = a and (relative distance) / y = b. Right now you have two equations: d1 = ax1 + bx1 and d2 = ax2 + bx2. So you need to solve those for a and b. I would divide the first equation by x1, then subtract the the second equation from the first. the ax's will cancel and you can get b. Then just substitute b and get a.
5. Now to apply the texture, we have to base the texture somewhere, so you should probably put the leftmost point on the left side of the texture dead centered vertically.
6. To calculate the pixel in the texture to use for a screen coordinate, here is what you do. X = (1 / (screenOffsetX * a + relativeSizeOfLeft) * screenOffsetX / totalXWidth * textureWidth) and Y is the same.
7. Then, take that pixel out of the texture and put it on the screen.
As far as I can tell, that should work. I'm sure if you actually do it, you'll find lots of optimizations. For instance, the reciprocal I forgot about at the end could probably be calculated earlier.
836
« on: June 14, 2011, 01:12:53 am »
Glad it finally works. The best part was that the problem wasn't even in the code you posted
837
« on: June 13, 2011, 05:35:20 pm »
There's only one person I can think of that has ever done that, he made Gemini. Looking through the source of that, you could probably figure out how he did it. At the moment, I can think of some ways to do it, but I'm not sure they would be fast.
838
« on: June 13, 2011, 04:12:00 pm »
...And this is why that boss actually can't teleport inside of you.
Well, maybe not inside you. But it could teleport right in front of where you are moving. (It happened  )
839
« on: June 13, 2011, 03:40:36 pm »
I don't think you would want to write a hook in Axe. Hooks are really assembly based, and Axe would not be able to even deal with the inputs and outputs for the hooks. Not only that, but I'm not really even sure what you could do from a hook with Axe that would even be useful.
Axe hooks would not cause issues for crabcake user though. Unless of course the hook uses crabcake, but that would just be bad programming.
840
« on: June 13, 2011, 03:36:24 pm »
I found a somewhat bug with this. If certain hooks run while crabcakes is doing its thing, the calculator will crash. Hooks are never going to expect that the extra ram page is in (05) and has meaningful data on it. Of course this is an easy fix if the hook developer knows about the problem, but some of the developers aren't going to hear about the problem, or are are long gone.
So what I would think you should do is backup the hook flags on startup, clear the flags for running the program, and restore them when you are done. There are only 4 bytes worth of flags, so that's not really a huge memory issue.
Although at first glance it looks like only 3 bytes $8A24-$8A26 are used for hooks, $8A2A is used for the USB hook. And while it's rare that this hook is active, it's the most likely to cause problems, so be sure to include it.
Pages: 1 ... 54 55 [56] 57 58 ... 108
|
Show Posts