Click here to edit contents of this page.
Click here to toggle editing of individual sections of the page (if possible). Watch headings for an "edit" link when available.
Append content without editing the whole page source.
Check out how this page has evolved in the past.
If you want to discuss contents of this page - this is the easiest way to do it.
View and manage file attachments for this page.
A few useful tools to manage this Site.
See pages that link to and include this page.
Change the name (also URL address, possibly the category) of the page.
View wiki source for this page without editing.
View/set parent page (used for creating breadcrumbs and structured layout).
Notify administrators if there is objectionable content in this page.
Something does not work as expected? Find out what you can do.
General Wikidot.com documentation and help section.
Wikidot.com Terms of Service - what you can, what you should not etc.
Wikidot.com Privacy Policy.
Discussion
My approach would be to think of 3 dimensions as a set of 3 planes (xy,yz,zx) to add 3 tangible surfaces. Each plane will judge its real position in space in terms of two dimensional formulas. From this position (x,y,z coords), the size as appears on the screen based on the viewing position. I would think of an objects as a set of points and then (in/de)crease the number of them by a fractal algorithm to create an entire object.
I have no experience with 3d, but that is my best approach. Try looking on cemetech for ideas.
Hey, I am going to waste as little of your time as possible. I just got a ti-84 + c silver edition 6 weeks ago and learned about coding it ~ 3 to 4 weeks ago. I only recently learned what apps were, though have made ports of simple games like flappy bird and am close with Tetris. I do understand the mathematics of this, as I do code PC games and work with other languages. I am new to this Ti-basic and Asm and BBC basic as well, but I hope to quickly learn. The reason I am posting this here is because of a challenge. I am going to make a fully working replica of Skyrim ported to Ti-basic. To do this I need a 3d engine. The game design and storage is my problem, so I will not ask anyone else for that.
What i really want to know is how far are you to being done with a 3d prism rendering&calculation program with xyz coords, length, depth, and height, and xyz rotation. Also how fast is it if it does exist, and if it is on Basic.
I don't know enough about this community to know if this is impossible, or already done. Thanks from Cyktoplasm
Not to rain on your parade, but I don't believe that the 84 has enough memory or processing power to completely port any game of that size. I would recommend that you move to the Ti-Nspire, which is much more powerful, and maybe down sizing the complexity of the game (maybe only one level). Just a suggestion.
It is definitely possible to make games like Flappy Bird and Tetris for the TI-84+CSE using ASM or another compiled language. It may be possible to make simplified versions using BASIC, but I think BASIC is better suited for games that don't require a lot of constant movement.
So…I was kind of wondering. I want to make a 3D game but I can't even get the basics down for a 3D engine (like making a rotating cube). An article for the code of one would be very helpful to me and probably many others…
I would love to Join even though I suck at programming
So…
A while has past, few things has happened…I still don't have a line alternative in asm and I have no clue how much intrest there is in this project: I believe much but we are facing a common problem: pushing over the edge…
we have gotten some pieces and I think that with the tremendous brainpower of this community we can assemble all these pieces. Yet, it has to be done: so the idea is, notify your status: are you still intrested? have you found anything new? etc…
Thank you
stay tuned please! we have come quite far, it would be a waste if we gave up now!
1. Thanks! I've thought of a way to support translation on the z-axis for prisms, but speed wise it would be like running prisms twice for each prism, so I'm not sure if I should do it… Also, I think that we should look into optimizing Builderboy's rasterization method, because it supports rotation, translation on z-axis, and is all-round more powerful.
2. Um, actually I found one a little while ago (almost). I used codex's rectangle drawing ability to replace 8 of the line commands, so that I draw 2 codex rectangles and 4 lines. This shaved quite a bit of time off of it, enough to (almost) double the prisms/second rate of my method w/ prerendering. That's nearly 10 prisms/second!!!!
3. I think that we should go either with a more limited but faster engine (my method), or a more powerful but slower engine (builderboy's rasterization).
4. Agreed, but we could use an already-built lib's rectangle drawing ability (like codex), since 8 of the lines drawn will form 2 rectangles. (at least in my method)
5. I suggest that the engine calculates, and we supply instruction on how to use variables, and (possibly) provide asm for faster drawing. This leaves the major decisions up to the individual game; like whether or not to get the variables early, and whether to use asm or not. This would allow programmers to aim for pure Ti-Basic or part asm, or provide it as a game option.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
It seems to me a BASIC engine just wouldn't be fast enough to make a smoothly running Basic game. While 5.5 prisms per second certainly is a remarkable accomplishment in TI-BASIC, I'm not sure if I would be patient enough to play a game that needs to render more than a few prisms per user input.
In my opinion, we could allow much better-quality games to be written by utilizing a prism-drawing engine written in full ASM, which does both the calculations and the rendering. By limiting the projection to zero-point perspective or isometric projection, and limiting the boxes to having segments that lie parallel to the x, y, and z axes, you could render even faster.
Perhaps we should consult/ask help from ASM communities, and brainstorm the features we would want in such an engine?
You know, in the idea of zero point, I have built an Isometric engine a while back. Here is an example of what the engine can do:
Here is the progress thread on Onimaga: http://www.omnimaga.org/index.php?topic=1028.0
If there is interest in this engine, perhaps we could consider using it as a type of Basic 3D engine?
This engine is writen with Basic with xLib/CelticIII support needed to run it
These are very good points. If we really want a great game running smoothly, we really need to move on from Ti-Basic, probably in the direction of asm or a library. Builderboy, when I saw your engine, I couldn't believe that Ti Basic was any part of it at all! An amazing accomplishment worthy of an amazing game.
I think that these are great ideas that merit the time and effort it would take for them to become a reality. I just think that these are different projects from the one that Matthias1992 set out to create.
Now let me make myself clear, I am not against using asm or libarys in this project. But really, the calculations are not what we would need them for; we can already do them fast enough ahead of time. What we really need in asm or from a library is a faster alternative to line(. That is where most of the time is taken up; just doing all 12 line( commands.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
Ahaha, I never ceased to be amazed by what can be done in TI-Basic. That looks excellent! Are you using xLib's tilemapping engine?
Yep! It gives a very nice and fast way to display rows. I am actually using CelticIII, but that supports xLib backwards compatibility, so most of the engine would still work with xLib (only a single line would need to be re-written)
First of all, I did not intend to make you feel guilty or anything like that but rather draw you're attention to the fact that decisions can be made this way without you agreeing with the actual decision (okay, bad explanation but I hope you get my point). As for graphmastur, Don't worry you may leave or join the project whenever you want. And as for _Abe_, It is perfectly fine if you stand on the sideline a little bit, once more no one is obligated to dicussing!
Thank you for your replies.
So, here it is, the fastest way I can dream up to get a prism on the screen. It uses my 1PP method, but without support for transparent in the name of speed.
Yep. That's it.
And the needed line commands… (whether they are in the engine or in the game)
…and there will be a quiz!
You may have noticed the lack of lists; that is because I ditched them in the name of speed, however that can be changed easily. I am also considering using the Finance Vars because of there speed. Yes, I know the last two can only be positive integers, but many of the variables I use will fit that bill.
So the input looks like this now:
When multiple prisms are on the screen all of the prisms will need to have the same v and w to maintain an accurate 3D effect, although it is not required. I haven't gotten to timing it yet though.
EDIT: changed 3rd line of engine to Thornahawk's suggestion.
EDIT: Included line('s 5th argument
EDIT: replaced 4 line of engine with 2 lines that fix a bug.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
Here are the timings, take what you want
Live Rendering
Total time to render prism: .25 seconds (includes calculations and line commands)
number of prisms/second: 4
Time for calculations: .08 seconds (just the 3D calculations)
% of time used for calculations: 32%
Summary: this method live-renders about as fast as rasterization with pre-rendering
Pre Rendering
Total time to render prism: .18 (includes setting variables and line commands)
number of prism/second: 5.5
Time to set pre-calculated variables: .01
% of time used to set pre-calculated variables: 18%
Summary: I don't think it can get much faster than this.
Now you need to remember that this method only supports drawing a prism of any size anywhere on the graph screen. No rotation or transparency support. This is a bare bones sort of deal I made just to see what the speed limits are. If only we had an asm equivalent of line(…
Just for those that care (probably nobody) I repeated the test lines of code 100 times for accuracy.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
Wow, nice and fast! Correct me if I'm wrong though, is there no way to move the objects themselves backward into the screen? And it seems the objects do not follow perspective correctly, as when you extrude the prism into the background, the lines to not approach the vanishing point :(
Thanks, I worked quite a bit on this rewrite.
You should compare the old prisms and this one side by side; It is like 1/4 the size!
Ah, well you are right on that first point. I said that this is a bare-bones sort of deal, and that is one of the drawbacks. This is true for all of my methods unfortunately. The only way to get around this is by scaling all of the prism's dimensions to give the appearance of receding/approaching. This of coarse would be handled by the game. As a general rule, to make it further back, make the prism smaller. We could probably find a simple way to do this consistantly if we decide to use this method. This is also a good case for us to use your method.
As for your second observation, yes, I know. My method isn't true 1 point perspective, only an approximation, but you can't really tell until the depth goes beyond about 30. Remember that this method was originally designed for cube field, where that wouldn't be an issue.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
wow! you made my day! these are very, very good results! I am so suprised about the calculations only to take 0.08 seconds! I have set myself on making a ASM alternative for "line()" because of it's slowness…This might take a while but If i am right I should get faster then (17/12) = 1.42 seconds PER line…that does not sound to hard given the speed of asm! I have put the results in the method testing table…
Thanks for your effort and time (same goes for anyone in this project)!
Thanks!
Good luck on the asm! …Sorry to burst your bubble but its .17/12=.0142 seconds per line. But on the bright side, if you can reduce time to draw a line by .0042, then it will draw a cube in .05 seconds less! That would get my method in live rendering down to the speed that the pre-rendering is now! That would also put my pre-rendering at nearly 10 prisms/second!
Just a side note, I think that instead of percentages, you should just actually record the time that it takes to do the calculations, rather than the percentages. Just my opinion.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
I'm still here… am I alone?
I have been working, just not with much progress.
As for using asm, I used the rectangle drawing abilities of codex to eliminate 8 of the line commands, which speeds things up a bunch, but it still needs some refining…
Anybody else still here?
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
I have just finished rewriting cubes to be compatible with the new prisms, but I ran into a problem.
When the prism is to the right of the vanishing point (that is, when V<S), this happens. Angles A and B are congruent. This happens regardless of what I use for the 3rd line of the engine. I have tested it with the following lines with the same results.
Please help me.
Thanks.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
Sorry, I'm feeling slow today… what exactly was the behavior of the prism you were expecting?
thornahawk
The lines connecting the 2 squares should be parallel to line from B to the vanishing point.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
well, in reality the should not be parallel, they should all be heading towards the vanishing point.
Yes, I know, if this was true one point perspective. I made the engine so that they are all parallel, which makes the calculations MUCH faster, while providing a good approximation. This is why the prisms seem to bow out away from you when you make the depth more than 30.
But my lines aren't even going in the general direction of the vanishing point. Please help me.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
I finally found the answer!
The 3 lines of code that I showed you all do the same thing, and all work great, the problem was in the next line of code. Sorry…
There are 2 expressions that get added togetherin this line. The second one needs to be negated if and only if V<S!
This is the simplest way I could think of to implement it.
Let me know if you can think of a better/more efficient way to do this.
I am now working on a way to support translation on the z-axis.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
Is N really supposed to be 0 if V=S?
Otherwise,
might be better…
thornahawk
Nice catch, but no, I made a mistake on the post.
It was supposed to be ≥, not >.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
In that case, the snippet I gave is equivalent to that edited version. Observe that S does not change in sign, but that square root is to be added if V≥S and subtracted if V<S. The short way is to multiply the square root by 2(V≥S)-1, which is 1 if V≥S and -1 otherwise (check it if you're skeptical!), thus ending with the snippet I posted earlier.
Alternatively, you use the identity
and simplify things from there. ;)
thornahawk
Your right, sorry. Must've been really slow that day, also made a similar mistake with deadlyfishy.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
Here is the code i used for my rasterization test. I store points and connections seperately so that all trig can be done on the points, and then connected once they are in 2D
I've been working on rewriting my Prisms engine, and found an optimization that I think would apply to your code as well.
That's 36 trig Functions!!!
I'm not sure if it would apply, but I was doing something very similar in my prisms engine (minus the "for" loop) and I found that I could replace the second trig function with the pythagorean theorem. This worked in my engine because I was finding the two legs of a right triangle when I knew one of the angles and the hypotenuse. My first instinct was to use sin and cos to find the other two sides, but when I went through the program again to optimize it, I realized that the second trig function was unnecessary because I had already found 2 of the sides of the triangle, thus pythagorean theorem would work better! In Prisms, this reduced the total number of trig functions from 3 to 2, and I doubt it made a huge difference. In your engine, if this optimization is applicable, it would reduce it from 36 to 18! I hope that this helps.
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
well, since it is prerendering the trig functions, it means that the time it takes to render the trig functions and store them into a list is not taking into account. If I wanted i could just as easily simply initialize the lists with raw data: {0,.012123985,.187450672,.598721347345…… -> L1. And that would save speed as well, but take more size. The general idea, though, is that when you initialize the engine (at the begining of your game or something), it precalculates the trig functions so that you won't need to do any trig at all during rendering.
Would my optimization cut down prerendering time?
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
Why yes it would, from a second to less than a second. The thing is, though, that since the prerendering is only done once, and before any 3D has even been displayed, the speed is irrelevant to the performance of the engine, and has little effect on the game as a whole. Better to optimize for speed in this case.
(any reason why you insist on using degrees? ;) )
I was hoping you guys were already aware of methods to save on trigonometric function evaluations (speed at the expense of increasing code complexity/size), but if not…
1. Symmetry
2. Trig Identities
3. Recursion
Generalizing these snippets (and proving that they work) I leave as an exercise in trigonometry. ;)
thornahawk
Well, if we are optimizing for speed, i have an optimization that is faster than any of those :P
{0,.34202,.6427,.86602,.9848,.9848,.86602,.6427,.34202,0,-.34202,-.6427,-.86602,-.9848,-.9848,-.86602,-.6427,-.34202,0 -> S
{1,.9396,.7660,.5,.1736,-.1736,-.5,-.7660,-.9396,-1,-.9396,-.7660,-.5,-.1736,.1736,.5,.7660,.9396,1 -> C
The fact is though, that this is not where we need to optimize for speed, this only happens onece, and it is before any 3D is even being generated. Whether it takes a second or half a second doesnot make that much difference because it only needs to be done once.
And I was using degress because it is easier to set up a for loop that goes to 360 in steps of 20, than it is to set up a for loop that goes to 2*PI in steps of PI/10. :P
If that application of yours can tolerate only having four to five significant figures, sure. ;)
As for going from 0 to 2π..
Easiness is relative. ;)
thornahawk
Ah yes, that would be a bit easier XD
And i only went up to 4 sig-figs because i had no desire to copy them all down, Google calc provides a fair amount :P But i think you got my point.
You mean that you didn't whip out your handy Ti and take them out to 9 digits?! ;)
"Reality is that which, when you stop believing in it, doesn't go away."
-Philip K. Dick
Now that I think about it, if you really don't mind the redundancy within the cosine and sine lists (you see the same numbers at least twice, ignoring the sign), you can strip down the recursive approach:
(Speaking of which, 20° is π/9 radians, not π/10…)
thornahawk