HOLY ...

Can't wait to see what you do with this!!!

It looks supprisingly well, but if you have to scale so many images at runtime, isn't 'normal' 3D or raycasting more efficient?
EDIT: but if they are pre-rendered (or rendered at the start of the program) it would indeed be more efficient.

Lol thanks, I was wondering if this would get any attention since people would look last night but not reply (except one person in the Youtube vid and Kerm on Cemetech) , but yeah, after seeing poor performance from a zoomed in mapper that I was drawing 5 times a while ago, I never thought that this 3D effect would be this fast.

There are some quirks, though:
-If you zoom out too far, it's very slow. On the other hand, it seems that adding 8 extra layers in front of the rest rather than on the back without zooming out doesn't impact speed that much. So basically, games have to remain close to the camera and if your levels are very deep, the game would probably have to only render the closest stuff, meaning that you wouldn't see very far.
-It is not wireframe. I could add a camera rotate feature so you can look to the left or right to a certain extent, but you wouldn't be able to look very far.
-Animated tiles are probably a no-go, unless levels or rooms are very small, since it would take a lot of space the way they are stored.


Now I'll need to make the engine portable before I can even think about making a game, though. For example, I need to ensure that camera angles and the perspective are perfectly aligned and that I can freely move around. I also need to make better graphics that are suitable for such engine. I hope that HP calcs supports functions with arguments, so that I can call the 3D function whenever I need it and possibly do some animations as well.

Nice, now implements a parralax scrolling lib!

Actually what I use is some extreme form of parallax scrolling. Notice how there are like 8 tilemap layers scrolling around at different speed to create the 3D effect. However, the layers are zoomed out rather than being the same size, and there's some sort of camera angle. The fact that it's parallax is why I considered pre-rendering every layer once, but that would probably fill the entire game RAM during runtime if levels were large. It would most likely improve speed a lot, though, because displaying non-scaled graphics is MUCH faster than scaled ones. Of course, pre-rendering would be out of the question if my engine ever added zooming in/out, since the scaling involved would defeat the point of pre-rendering everything.

It looks supprisingly well, but if you have to scale so many images at runtime, isn't 'normal' 3D or raycasting more efficient?
EDIT: but if they are pre-rendered (or rendered at the start of the program) it would indeed be more efficient.

I once tried to pxl-on the entire screen, pixel by pixel, and the results were not convincing. In my engine, the entire tilemap is actually pre-rendered, just not the scaling effect. Filling the screen with lines one by one isn't too bad, but I worry that the more complicated calculations involved in raycasting would make such engine even slower.

EDIT: On a side note, if the engine is used for a top-down view game rather than side-scroller, I could just rotate the camera angle effect

I mean stuff like in computer languages, such as:

prgm Zelda()
<code>
FadeOutEffect()
<more code>
func FadeOutEffect()
<code for fadeout effect>
Return
End

IIRC, the TI-89 and the Nspire supported them and I heard that the Prime did too, but I wasn't sure. I know that the 84+CSE lacks functions, which requires you to use external sub-routines or extra variables. Not that the lack of functions would be much of an issue for me, but it would make it easier to code if they are actually supported, since I could easily call my map engine from anywhere I want.

EDIT: By the way, I can now display the frame rate in real time. Here's how you do it:

At the beginning of your loop, add the following code:

TICKS->T
Then at the end, add the following:

TEXTOUT_P(IP(1000/(TICKS-T)),G0,0,0,1,RGB(255,255,255));

Oh ok. To be honest, though, since I used TI-BASIC for so long, it took me ages to understand a bit about how functions work, and I had no problem working without them since I knew how to get around it (for example, using an extra variable to detect when I need to get out of a loop then enter a new one when needed).

In fact, maybe I should try things that way on the Prime too then try functions, just to compare speed, in case there would be a difference (we never know. After all, TI managed to make Lbl/Goto and running sub-programs brutally slow).

It depends if you used them properly. If you put a Goto inside an if:then block or a While/Repeat loop (basically, before the End command), the memory that the block/loop took will never get cleared. As a result, Gotoing out of a block/loop over and over slowly depletes your RAM, causing slowdowns then an eventual ERR:MEMORY.

Even when used properly, however, Gotos are still slow. Back when they were used on a regular basis, it was semi-common to see games coded like this:

Goto 1
Lbl 2
<very large gameplay code>
<Game over>
Lbl 1
<title screen code>
<menu code>
<Goto 0 to exit>
<Goto 2 to start game>
Goto 0
The lower a Lbl is inside the code, the longer it takes to reach it, even if the Goto command was right next to it, because Goto starts searching from the very start of the program.


Also, in some rare cases, using Lbl/Goto was actually faster than While/End. If the loop was very small and placed at the start of the code (such as the example above), that is. Otherwise, the speed was just atrocious. Even in cases where it's faster, however, the speed gain is usually negligible, especially on the 84+CSE, where drawing huge shapes or images is slow.