No, I am completely redoing the game again (but more optimized) and the world generator is being redone with looking ahead to bigger mechanics, since I am using GROBs for map data I need to recode the game (again), but a big plus is the collision will be super accurate because how PIXON_P() works ex:

PIXON_P(25,25);
//Works the same as
PIXON_P(25.99999999999,25.999999999)

Both of those will display a pixel at (25,25) even though one is almost 26 it will still not round up!

Is the recoding the one you restarted recently or are you actually restarting the game from scratch as of today?

Also yeah I like how decimals work on the HP Prime for graphics.

That screen shot is from one day of work (but that was a few days ago ) now I am working on rendering and VERY simple world gen (superflat world like the CW server xD) just so I can implement and test player movement.

For world gen I have these vars: OreSpawnFreq, TreeSpawnFreq, WaterLevel, OreSpawnLevel, TerrainNoise, WorldName, SizeX, SizeY. and I am nowhere near figuring actually using them all

I ran into a slight (ok very major) problem. It is going to be very hard to use GROBs to store data in, the values I found increment by eight. so if you store 20 in a pixel it will round to 24 (ok so no big deal just add 8 instead of one and when you need to get a value just divide the GETPIX_P() val by but logically the next step would be 32, right? Well nope, it is 33 I don't know why but it just does that, I have used other values and it isn't too major. 80 turns into 82, that can be fixed by doing this: IP(GETPIX_P(G9,0,0)/8) but if it fluctuates to much it could display the wrong block. I will look and see if I can get around this tomorrow. If this is a bug I hope @timwessman can solve it

Hm that sucks man. I hope there is a workaround. I assume this is for tilemapping, right? What about tile based collision rather than pixel by pixel?

Yeah, this is for the map, I still could use it for collision but I would still have to use a matrix for the map, this still might be accurate enough though, I could even choose values that would work. I have not run into any problems that I have noticed, maybe it is not exponential on how much the value changes from what it should be. I don't know as I haven't really tested it too much yet . I hope tim contacts us, I will make a topic on hp museum just in case

I think I can make it work tho it will be much harder to do so

I think matrix-based collision would still be fine. It would just be akward. For example you would probably need to divide the character position by 16, but keep track of the decimals so that when they are higher or lower than a certain amount (depending of which direction you are facing and if you are jumping or falling) to check for walls. Or you could just go the cheap route of centering wall boundaries in the middle of the tiles and allow the character to move 8 pixels into walls.

I wouldn't wait until the bug is fixed, though, otherwise it could take like half a year before MinePrime resumes

Yeah, no kidding, but I used matrix collision for Zampy's quest and I had to majorly optimise it for it to run that fast, pixel collision would be blazing fast. For example if Zampy's quest was written with pixel collision it would be at least 2.5X faster, so fast I would have to slow it down. That is because with matrix collision I had to calculate 4 places in the matrix if you were moving left/ right/ jumping if you were moving left/ right while jumping then it has to calculate 6 places simultaneously slowing it down tons. Pixel detection is not only faster but if each pixel represented a block the max pixels you would have to check would only be 2 .

Post from HP Museum

Quote from: alexgt

Quote from: Tim Wessman

Why? 75000chars*2 bytes, will be much smaller then a graphical representation.

my_string:="1234"
mystring(3)  --> 3
mystring(3):="4" ->"1244"

That last one will even do direct access to the string - no memory allocations involved - so it should be rather fast too.

I think what I will do is make a list that is the height of the world and store strings in each of those elements

So progress will resume

So can we expect a new screenshot soon? I'm excited to see this progress more, I may buy a prime soon...

Well, no moar progress has been made since the last one, but I have found a solution to world storage as you saw. So I will start on world creation and then get cracking on other stuff

Thanks for the tip about strings by the way. I use them for map storage in some BASIC games and it's usually quite small. But it can be weird to replace a string element.

*poke*

This thing still alive? it's been a month since the last update.

This is not how to poke. You must do *pokes @alexgt *

I didn't even notice who started the project...then again, I didn't notice when I became a Super User...