[Minecraft] [HP Prime] MinePrime - Minecraft on a Hp Prime!

[Dream of Omnimaga]

Yay! How long does it take to load a world now, by the way?

[alexgt]

Currently it takes 2 seconds to load a world (that time will probably not change). And to generate a new world takes 9 seconds, that will vary since world generation will be much more complex latter

[Dream of Omnimaga]

that's not much! I remember the last public version took over 20 seconds to load worlds. 

Also I thought of something: I wonder if the game would slow down too much if you added a pseudo 3D effect to the map with a background? That's assuming you have enough space for extra sprites, though, although you could always just use plain rectangles. Basically, what you would need to do is have about 8 map layers, one with 16x16 tiles (the current layer), one with 15x15 blocks, the other 14x14, then 13x13, and those extra layers would scroll slightly slower. All tiles would be pre-rendered in a GROB, unless they're just rectangles with a gradient. Basically it would be parallax scrolling with 7 parallax layers, except they would be very close to the front layer and just be slowed down slightly.

[alexgt]

UPDATE!
- Fixed world jittery bug (made one zero into 0.9375 )
- Now camera movement is sorted
- Noticed bug with world rendering and have to fix that
- Closed BETA will be released at the end of the month (tomorrow )
- Remember to email me if you want to be in closed BETA !

that's not much! I remember the last public version took over 20 seconds to load worlds. 

Also I thought of something: I wonder if the game would slow down too much if you added a pseudo 3D effect to the map with a background? That's assuming you have enough space for extra sprites, though, although you could always just use plain rectangles. Basically, what you would need to do is have about 8 map layers, one with 16x16 tiles (the current layer), one with 15x15 blocks, the other 14x14, then 13x13, and those extra layers would scroll slightly slower. All tiles would be pre-rendered in a GROB, unless they're just rectangles with a gradient. Basically it would be parallax scrolling with 7 parallax layers, except they would be very close to the front layer and just be slowed down slightly.

Yeah, I am pretty happy with that, the reason why it loads so fast is it only has to generate the collision map

For the pseudo 3D effect I think that it would  slow it down if you did eight layers but  it might work. As of now I have the game loop running with out any time restrictions and it  is running at about 3x as fast as I would like so it may be possible without any noticeable speed drops . and also I could turn it on/off in the settings ..

[Dream of Omnimaga]

Yay! I can't wait for the closed beta release. Glad you got most issues sorted out

[alexgt]

awesome! I will hopefully stomp out that bug

[Dream of Omnimaga]

I missed your 3D comment for some reasons. The trick to avoid lag would be to pre-render every zoomed sprite rather than redraw them everytime. Or you could render them at full size then display the final result zoomed out, which might still lag a bit but not as much as zooming out two entire rows/columns of tiles one tile at a time. But yeah at 8 layers there could definitively be noticeable lag.

[alexgt]

Well, I was talking about the lag from displaying the grobs on top of eachother. If I were to do this I would probably use some tileable backgrounds like the ones is Super Mario Bros

[Dream of Omnimaga]

Oh ok. Yeah I meant tileable backgrounds, but with the same layout as the front map (you would need to update 8 times as many left, right, up and down rows of tiles in map layers, though, which I think might be where the slowdown would occur. It's up to you, though. Just 1 layer of parallax scrolling (maybe a tiny row of clouds at the top, not a fullscreen background?) and the sun/moon would be fine.

[alexgt]

Yeah, I think 1 layer would add a lot with no slow down

I will be emailing the BETA to all my testers within 30 minutes

[Dream of Omnimaga]

Cool. I'll check my e-mails out

[alexgt]

Just sent it

[Dream of Omnimaga]

It doesn't work @alexgt  . It just shows the Y= equation screen straight at startup, both in the Virtual Calculator and real calculator. I tried an hard reset and the ON+SYMB soft-reset, then I tried running a program that contained the following at the start, to no avail:

Code Select Expand

DIMGROB_P(G1,1,1);
DIMGROB_P(G2,1,1);
DIMGROB_P(G3,1,1);
DIMGROB_P(G4,1,1);
DIMGROB_P(G5,1,1);
DIMGROB_P(G6,1,1);
DIMGROB_P(G7,1,1);
DIMGROB_P(G8,1,1);
DIMGROB_P(G9,1,1);

Even after formating my calc via the F C O menu it didn't fix it @alexgt . I think your app is corrupted upon transfer because I clicked the APP in the connectivity kit and the program source is empty. Or it might be exclusively compatible with 10077.

And this, @timwessman , is why I have been insisting for a year that the ICON command inside regular .hpprgm files remains compatible with future firmwares as long as .hpappdir transfer and execution becomes 100% functional.


EDIT: By the way I just upgraded to the newest firmware. This time the program code shows up in the connectivity kit, but the app still won't run. It just shows a spreadsheet. If I try to edit the code, I get a Syntax Error on Line 75 (Tri()

[alexgt]

Check out my last post: http://codewalr.us/1301/39451

I will definitely check Line 75

My spidy senses are telling my that it is to do with storing vars in the actual spread sheet app I will fix that, send you a copy and see if t works

[Dream of Omnimaga]

Maybe you might have to avoid relying on app-specific vars and stick to local/global vars, in case. That's unless there is a way to send those vars as part of the app. But it's definitively not an issue on my end since even a freshly formated calc could not run the game and none of the symptoms you mentioned in the other thread happened. That,s unless I am doing something wrong during transfer but I followed your tutorial as described.