Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => Topic started by: boot2490 on February 21, 2012, 07:21:41 pm
-
(http://img.removedfromgame.com/imgs/concept.jpg)
What do you think?
...Mario Kart on the 83...?
-
It kinda reminds me how DJ got his dungeon map generated, which was about generating map based on a "minimap" he stored in the Picture file.
But I wonder how fast will that mode 7 thingy be with TI-BASIC O.o
-
Probably AXE.
-
I think it's probably more like wireframe 3d than mode7. I suppose it could be faster than mode7 because it doesn't have to loop through each pixel on the screen, but it does look rather lonely :P
-
It would look better when it was animated.
And it would be SO much faster!
How would it work, though? How would it know how to translate the points from the lines on to a plane sort of thing?
-
It kinda reminds me how DJ got his dungeon map generated, which was about generating map based on a "minimap" he stored in the Picture file.
But I wonder how fast will that mode 7 thingy be with TI-BASIC O.o
It was 2D, though, and didn't use lines.
However a racing game attempted a similar method in the past I think, or maybe it was a different one, but it still drew tracks with lines. It had slopes, though:
http://www.ticalc.org/archives/files/fileinfo/126/12690.html
It didn't support clipped lines, though (as you can see, it doesn't use the entire screen)
-
I was thinking, for the one I actually made, that the line positions would be predetermined, like 20 or so possible track pieces.
-
Though, it's not like my mode7 engine is super slow, either. The current version of it gets about 19 frames per second at the 15MHz speed (and the framerate stays pretty constant -- the line drawing method's speed could vary greatly with the number of lines that are onscreen)
Edit: Of course, not to discourage trying this method at all.
-
I have no idea how it would translate the line data onto a mode7 style 3d plane. Like, no idea almost. almost... I think I got it... not quite. Something to do with it finding the points within that view cone thing... lost it. How does yours work?
-
How would collision detection work, by the way?
@Calc84maniac that's in ASM, though, right?
-
Probably with a pixel test of sorts, but what about offroad, is the question..
-
Well, I actually translate pixel coordinates into world coordinates for the mode7 renderer, not the other way around. However, I do occasionally have to translate world coordinates into pixel coordinates, in the case of the movable sprite objects. Basically, I get the relative offset from the camera by subtracting the camera coordinates and then rotating that offset by the camera angle (which requires some multiplications by the cosine and sine of the camera angle). Then I calculate the pixel row and column by using some division and stuff.
-
The way you explained that using such casual terms makes it sound like it's all just trivial, obvious calculations. :P Just made me laugh, that's all...
-
Haha yeah, I just don't want to get the exact calculations unless it's really necessary, because I don't feel like deciphering my old code :P
-
So, it would calculate a trapezoid, and find all of the lines that show up in that trapezoid. At the bottom of the trapezoid, or the "camera", the points remain the same, relatively speaking, and they are drawn on the bottom of the screen. However, points that show up at the top are moved in towards the middle of the trapezoid, width-wise, according to how far they are away from the viewer, or how close to the top of the "perspective cone", and are drawn closer to the horizon line.
Like this:
(http://img.removedfromgame.com/imgs/doesthisexplainit.jpg)
-
A trapezoid would make the math easy, but you also have to make sure to squish the lines closer together the farther they are from the players view. The farther points are from the player, the more they are 'squished' in the Y direction. I'll see if I can draw up the correct math, I think it might be relatively simple
-
That's what my ENTIRE last post was about. I guess I am bad at explaining things.... Points closer to the wide end of the trapezoid get squished in. That is why it is a trapezoid. The trapezoid is transformed into the rectangle view. Like, if you cut out the part with the trapezoid, and then squished the ends so it was a rectangle, it would look like a rudimentary mode seven.
-
basically you're wanting to draw a wireframe of the track in 3D instead of the rotating+scaling ala 'mode7' like in fzero? This idea has been mentioned before yet hasnt been overly explored.
-
Yeah I think he wants to do something like GlassCars, but instead of having slopes, he wants to make everything flat. Basically zDoom/Doom 83 engine with lines at the bottom of the screen instead of full walls.
-
With appropriately designed tracks the calculational demand per frame might not be too intensive. Of course you wont get as much detail but you would still have a nice track to follow.
-
Yeah true. If his tracks are very huge and complex, though, he might have to find a way to not have to display everything that is far ahead, like in old Nintendo 64 games when far away terrain did not appear completely.
-
^^^^ (last four posts?)
My thoughts exactly.
My rotation is not working STILL though, rotating the wrong number of degrees. I think I am close to a solution though, so I will keep yinz posted. Once that is done, all is left is porting to AXE (from basic) and optimization.
-
Yinz? ???
-
Do you have the math locked down or is it the translation to code at this point?
(just wondering how you are calculating your rotations?)
-
Yeah true. If his tracks are very huge and complex, though, he might have to find a way to not have to display everything that is far ahead, like in old Nintendo 64 games when far away terrain did not appear completely.
Lod system, level of detail, which decreases when the distance increases
-
Wow great explaination! ;D
edit this is what you get when not checking for newer posts :P