Omnimaga
Calculator Community => HP Calculators => Topic started by: DJ Omnimaga on November 09, 2013, 08:29:38 pm
-
I was experimenting with the BLIT_P and DIMGROB_P commands then modified my scrolling sprite sheet program, and this is the result that I got: Pseudo 3D graphics running at 16 images per second (160x120 resolution) on the real calculator! *.*
Ok I know this is a particularly cheap way to do it, but if you changed the background of the front graphics to a texture that can be superposed fine (such as the bricks, plain tiles or rocky stuff), it would work well. Now imagine if every layer were pre-rendered into a large GROB, so that no scaling is done during runtime (except the weird camera angle effect).
EDIT: Replaced large GIF with youtube video
EDIT 2: I fixed the transparency issues causing purple to appear.
-
HOLY ... *.*
-
Nice, now implements a parralax scrolling lib!
-
Can't wait to see what you do with this!!!
-
wow, just wow, that is so epic!
/me suddenly imagines Majoras Mask on the prime :P
-
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.
-
That is fantastic O.O Wow. :thumbsup:
-
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) :P, 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. :P 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 :P
-
I'm not an expert in the gaming arena but this does look rather good me! I know you're already over the top in points terms, +1 nevertheless. ;)
As a side note, BUT, BUT what do you mean by: "I hope that HP calcs supports functions with arguments ..." What?? O.O
-
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));
-
... I know that the 84+CSE lacks functions, which requires you to use external sub-routines or extra variables.
Well, this is really ancient programming practice, imho, hence my astonished question.
-
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).
-
(we never know. After all, TI managed to make Lbl/Goto and running sub-programs brutally slow).
Not only Gotos are slow but they also slow down progressively. I once made a loop with a Goto (when I didn't know about While yet (that was a while ago, see what I did here ?)) and noticed that the game was running slower and slower after each iteration.
-
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.
-
(http://img.ourl.ca//hpprime3dupdate.gif)
-
/me wants
-
WTF? is this a deaf-mute conversation? :P
Btw, the speedy thing is getting better and better.
-
And now imagine this thing with assembly......
-
DJ Omni, many front layers like this is quite funky, you could try with real layers, with front decor layers, and rad layered background. THat would be more beautiful.
Anyway, nice finding, and good work DJ! ;)
-
DJ Omni, many front layers like this is quite funky, you could try with real layers, with front decor layers, and rad layered background. THat would be more beautiful.
Anyway, nice finding, and good work DJ! ;)
Oh I actually use two different tilesets for the layers. Notice how the front is different than the sides. However, I can't add much more, else the program gets way too large and it would take too much RAM for tilemap storage.
I already suspect that I might be using too much RAM, because if I try editing the code after running the program, the calc freezes, and if I run the program after opening the editor, the tiles don't appear.
By the way, the reason why the blocks are so thick is because I planned to use 64x32x3 tilemaps. Each block would actually be 3 layers, so the current screenshots demonstrates three identical maps on top of each others. Also, this is where memory becomes an issue: Because generating the tilemap on the fly would be too slow.
Of course, however, it could be due to how large in width some lines of code are. Some lines of code are 19000 characters long and there's no word wrap. I need to check if we can split sprite data into multiple lines to see if it would be better.
Of course, in the worst-case scenario, I can always generate sprites with a bunch of rectangles or just use plain squares. :P
-
Changed topic title because I just noticed that the current version of my engine actually ran at 21-23 FPS on-calc (I had the emulator version slowed down to what it used to run at on-calc.)
Also, since the HP Prime supports sub-programs, I decided to split the sprite data into 6 sub-programs. This sucks for people who hate games that uses multiple files, but I seem to get fewer crashes from code editing now.
-
Also, since the HP Prime supports sub-programs, I decided to split the sprite data into 6 sub-programs. This sucks for people who hate games that uses multiple files, but I seem to get fewer crashes from code editing now.
Good :)
I think people will have no choice but to split large programs.
-
Yep. Even if you only use the emulator, the connectivity kit still can't detect programs this large in it. Of course if they are split in chunks it's still slow to detect them on a real calc, though (between 1 and 10 minutes each, while smaller ones usually takes a few seconds)
-
And now imagine this thing with assembly......
Yeah, at first, they (HP) do look very open minded, don't they? But then we can't access the machine very power. That's a shame really, oh well. :P
... the connectivity kit still can't detect programs this large in it.
Hmm, why is that? How large a program are you talking about?
-
And now imagine this thing with assembly......
Yeah, at first, they (HP) do look very open minded, don't they? But then we can't access the machine very power. That's a shame really, oh well. :P
... the connectivity kit still can't detect programs this large in it.
Hmm, why is that? How large a program are you talking about?
64+ KB each. Although HP seems more open-minded towards coders, they still have a long way to go in terms of releasing reliable softwares and products (although at least they monitor calc forums for bug reports, so it shows that the programming team care.). However it's not just a problem with calcs: My last two printers from HP lasted about 20 uses before they started jamming for absolute no reason and their computer softwares, such as Hardware diagnostics are incredibly slow for what they do. Don't wonder why they almost went bankrupt two years ago.
-
That's quite strange, never had a problem with their printers. But just install the drivers, never install their softwares... You gain around 300 MB like this.
-
That's quite strange, never had a problem with their printers. But just install the drivers, never install their softwares... You gain around 300 MB like this.
*300 GB. :P
Also tif you buy an HP computer, their pre-installed softwares cannot be uninstalled unless you reformat the computer.
-
That's quite strange, never had a problem with their printers. But just install the drivers, never install their softwares... You gain around 300 MB like this.
*300 GB. :P
LOL! Not that much, but not very far either. :D
-
I didn't have much motivation to work on the 3D engine due to being exhausted from my weekend of work, but yesterday I was bored and did something quite cool looking with my background images :D
(http://img.ourl.ca//fireeffect.gif)
Basically this just involves scrolling through my original background images, stretched so that one column of pixels fits the entire screen. :P
-
that's looking pretty sweet!
(sigh, color calculators are so awesome)
-
Good luck doing that on a color 84+ or a J or K TI-Nspire, though. :P (although otherwise they can still pull some awesome games)
-
Project halted until further notice.
-
Project halted until further notice.
Oh, are you working on anything else or what is keeping you busy?