I'm still pretty sure I'm just going to use a spare RAM page.
I'm still pretty sure I'm just going to use a spare RAM page.
You know, what I do in the PC version for earthquakes is instead of digging a one width tunnel, I'll dig it two wide. During earthquakes it's just shifting it to the right or left, and two wide makes it easier to find, so I can reclaim the lost distance.
Well, asm programs can access them, but outside of a program, the calculator will crash if they are used. You have to be careful, but there is more RAM for programs to use.How would you actually use those pages through Axe/Axe inline ASM?
And don't use undocumented functions plz :PWill the use of an extra ram page work on the Nspire?
I vote for the page that all the calcs except the 83+ has. :)
Yeah, I have to admit that unfortunately, nSpire compatibility is not my number one goal.
Hmm i guess its SirCmpwn's decision on to how to implement the RAM he is going to use then
What do you mean by not working in saving? Do you mean extra RAM pages are not writable the way we do with regular ones?
I wonder how Sir's gonna do it. RAM pages don't work in saving, remember.
They are writable, but not guaranteed to remain intact. I guess I could have a checksum type of thing where it would only let you load it if the checksum worked out.
Yeah, i agree on this one. Either have a 100% reliable saving mechanism, or just go with the idea of not being able to saveMy thoughts too. :)
Yeah I hope this is successful. I wonder if there are any similar games for calc right now? It might be a first.i think its definetly a first...
Yeah I meant games where you dig in the ground and stuff, or even stuff like Lierox. There was Tinyworms but that did not really involves digging and stuff.Yeah I hope this is successful. I wonder if there are any similar games for calc right now? It might be a first.i think its definetly a first...
never saw anything of this scale on a calculator ever before...
except perhaps some rpgs and stuff... but those dont have to keep track of this much data at a time...
oh... i see...Yeah I meant games where you dig in the ground and stuff, or even stuff like Lierox. There was Tinyworms but that did not really involves digging and stuff.Yeah I hope this is successful. I wonder if there are any similar games for calc right now? It might be a first.i think its definetly a first...
never saw anything of this scale on a calculator ever before...
except perhaps some rpgs and stuff... but those dont have to keep track of this much data at a time...
http://www.ticalc.org/archives/files/fileinfo/266/26607.htmlhmm... i see... so it was an attempted worms warfare clone...
I don't think you did but it looks like Magic Banana and Raylin are interested in working on them ;D
Well, I had a few minutes so I whipped this up real quick. The vehicle can use a little work as it's a little plain, but the drills came out nicely.wow... that looks pretty nice actually!!!
For some reasons I think he might have moved to a different digging game called Dig Dug, but I could be wrong. I got that impression when he requested Dig Dug sprites as I doubt he would be working on two similar games at once.I believe he is working on both. ;D
x.x why did you have to bump this :PAwesome. :) * ZTrumpet wishes Sir and his band good luck for the rest of the season. ;D
I don't have much time, but I'll try to get on top of it later. Marching season is almost over, I'll have extra time soon.
Band ftw!nice!SaxophoneClarinetSAXOPHONE == Best instrument.
Edited by SirCmpwn
You, my friend, are my favorite now. That is all.Band ftw!nice!SaxophoneClarinetSAXOPHONE == Best instrument.
Edited by SirCmpwn
shakugan no shana :)
love that anime too...
[. . .]
Piano FTW.Yay I was worried about where you went. I hope you both have more time soon :)
have fun marching! Cross Country season actually ends today, so now I'll have lots more time on my hands.
Hey, I know what I'm doing. I do have good ideas occasionally :P besides, it will be open source, so if you don't like my approach, you can always change it.
Item Mass (kg) Value ($)
treasure 5 000
martian 10 000
artifact 50 000
ironium 10 30
bronzium 10 60
silverium 10 100
goldium 20 250
platinium 30 750
einsteinium 40 2 000
emerald 60 5 000
ruby 80 20 000
diamond 100 100 000
amazonite 210 500 000
fuel 0 2 000
repair 0 7 500
dynamite 0 2 000
plastic explosive 0 5 000
quantum teleport 0 2 000
matter transport 0 10 000I can work on this on my cruise at night.
Who says it has to be mr natas anyways? It could be at 1000 blocks and be cthulu. :Plol :P
I made an app that lets you view a 44x666 4 level grayscale smooth-scrolling map. Now for gameplay.So, 22x1332? If you were really awesome, you would make it go 42x1337x666, but I guess this doesn't support 3D. ;-)
thats why I suggested going down 666 feet instead of 6666. ;)Keep in mind that the blocks in the original game were 11-12 feet tall. If I remember correctly, the map was 7400 feet deep, so the level is about 650 blocks tall, meaning SirCmpwns map the correct size.
I am confused. This is axe right???
-A 44x666 smooth scrolling 4 level grayscale map
This game runs in 15 MHz right now.
Wow I didn,t know phones could take pics that big. O.oMany phones have 3MP cameras now :P
Also perfect grayscale isn't necessary. Just as long as it doesn't look terrible when scrolling to the point where we barely distinguish anything.
Glad you guys like it! It looks a lot better on the emulator than it does on-calc, though :P
By no means does it look bad on-calc (try it yourself! :P), but the emulator certainly glorifies it.
3 level still looks fairly nasty while scrolling. In The Mighty Jill off all the black pixels run together.yeah true. I guess if possible it's just best to display a checkered version of the gray that won't move at all. When scrolling it will move anyway, creating a gray effect.
This looks very great Sir. If you used 3 levels grayscale I would have suggested to simply freeze the grayscale during vertical/horizontal scrolling and have it work when not scrolling or when scrolling diagonaly, but this wouldn't work at 4 level I think...
Good luck on the buildings. I just saw your screenshot, and...YOU ROCKThanks! Glad you like it. I think I'm just going to have to use some sort of secondary tile map.
Well, when it moves, even though it doesn't change the checkered pattern, the LCD delay is still there, so it mucks with other pixels.
I love it just the way it is. You can see left and right plenty, and Up and Down don't need as much visibility.Thanks! I'm really satisfied with the quality of the HUD.
Hmm..perfect-grey axiom...That would be near impossible to do.
perfect gray can be obtained without and axiom ^-^ and I think sir's grayscale is well planned out in the renderloop, it looks quite good on emu.I DispGraphrr three times in a row to cycle the grayscale before moving on in the loop.
That looks amazing. The views are perfect, as willrandship said. It's looking a lot like the original game :DThanks lots! The HUD is a lot better than the last one, IMHO, but it will require me to make my own text routine and rotate a line to represent the fuel. The HUD is actually a big spot for inefficiency, so I'm not sure how I'm going to take care of the rotation quickly. As it is, I pre-render the HUD and store the image of it in memory, then copy it back to the screen each frame. I don't re-draw it.
I DispGraphrr three times in a row to cycle the grayscale before moving on in the loop.
But wouldn't that leave one of the cycles on the screen longer than the others?Yes, it does. However, after lots of testing (I spent a few hour fine-tuning grayscale), the result from this method is the best. You can see in the demo posted a few pages ago on your own calc, it looks pretty good this way.
Hm the HUD is a bit big for my tastes. Is the title motherload really necessary? You could save space by shrinking the fuel gauge a bit and removing that.I'll consider it, and perhaps do some more testing, but I kind of like having the title there. You don't really need too much vertical space on the map to play this game.
I was thinking about problems with the final boss fight but now that I think about it it shouldn't be much of a problem.With the final boss, I was considering removing most of the HUD, actually. I'll look more into it once I get that far. Also, I misspelled "Integrety" on the HUD.
Hm the HUD is a bit big for my tastes. Is the title motherload really necessary? You could save space by shrinking the fuel gauge a bit and removing that.I'll consider it, and perhaps do some more testing, but I kind of like having the title there. You don't really need too much vertical space on the map to play this game.
O.O woah this look awesome! I agree that the HUD is a bit too big, though. I like the ones you posted better. I personally like the ones with non-damaged text, because they're a bit easier to read. What is the gray bar thing, though?
I also have a small placard in two of them, that can accommodate up to four characters. Any suggestions on what these characters should be? Perhaps an alternative thing to put in that space? It feels kind of dull when there is nothing there.
Hmm....what about having a button that gets rid of/brings up the HUD? Then you can play fullscreen, but run the risk of not seeing your fuel.I can look into that, but keep in mind that the map scrolling may be impacted by allowing that to be defined with a variable.
Yeah, I'm doing a smaller HUD, so you get one extra row of tiles.
Attached is a GIF of the new version.
{16*12+0+L₆}ʳ→{0+ᴇBE6A}ʳ·ᴇ0080﹢ᴇ0360→{16*12+0+L₆}ʳ
{16*12+0+L₃}ʳ→{2+ᴇBE6A}ʳ﹢ᴇFF7F→{16*12+0+L₃}ʳ
{17*12+0+L₆}ʳ→{4+ᴇBE6A}ʳ·ᴇ01C0﹢ᴇ0E38→{17*12+0+L₆}ʳ
{17*12+0+L₃}ʳ→{6+ᴇBE6A}ʳ﹢ᴇFE3F→{17*12+0+L₃}ʳ
{18*12+0+L₆}ʳ→{8+ᴇBE6A}ʳ﹢ᴇFC1F→{18*12+0+L₆}ʳ
{18*12+0+L₃}ʳ→{10+ᴇBE6A}ʳ﹢ᴇFC1F→{18*12+0+L₃}ʳ
{19*12+0+L₆}ʳ→{12+ᴇBE6A}ʳ﹢ᴇE003→{19*12+0+L₆}ʳ
{19*12+0+L₃}ʳ→{14+ᴇBE6A}ʳ﹢ᴇE003→{19*12+0+L₃}ʳ
DispGraphʳʳ
{0+ᴇBE6A}ʳ→{16*12+0+L₆}ʳ
{2+ᴇBE6A}ʳ→{16*12+0+L₃}ʳ
{4+ᴇBE6A}ʳ→{17*12+0+L₆}ʳ
{6+ᴇBE6A}ʳ→{17*12+0+L₃}ʳ
{8+ᴇBE6A}ʳ→{18*12+0+L₆}ʳ
{10+ᴇBE6A}ʳ→{18*12+0+L₃}ʳ
{12+ᴇBE6A}ʳ→{19*12+0+L₆}ʳ
{14+ᴇBE6A}ʳ→{19*12+0+L₃}ʳ
what about having physics use onscreen coordinates with a map offset?That wouldn't work too well, because of the size of the map, and some dirty tricks I'm going to have to do for the surface map and the boss.
For grayscale are you planning to release a map demo so people can see how it's like? Maybe it will be fine so you don,t have to remove it completely or something.I'll release another demo on Wednesday, when I'm sure I'll have all this crud sorted out.
you might do what I am doing with my Pokemon game.Accessing files like appvars is difficult considering that all RAM from 0x8000-0xBFFF is inaccessible, and most OS routines are not able to be used.
I currently have over 10k bytes of sprites so far (still increasing)
I have it stored as an archived app variable.
I know it is a pain making people to have more than one thing in their memory, but it can be a life saver.
Hmmmm that does pose an interesting problem. Basically you are needing all 100% of code and data present to be stored in the App itself?That is correct.
You can't use files if you are using an app!???you might do what I am doing with my Pokemon game.Accessing files like appvars is difficult considering that all RAM from 0x8000-0xBFFF is inaccessible, and most OS routines are not able to be used.
I currently have over 10k bytes of sprites so far (still increasing)
I have it stored as an archived app variable.
I know it is a pain making people to have more than one thing in their memory, but it can be a life saver.
You can't use files if you are using an app!???You can't use files if you swap in a spare RAM page and take control over the whole calculator, which I do. I can't use very many OS routines this way.
If yes. Oh S*it
Hmm...How much of the drilling animation could be reused? Right now, it seems to be size over speed for them, so having them as several subroutines (esp. particles and such) might decrease the space. Can you do sprite flipping, to shave it to 2000 bytes?Well, digging as it is right now is just removing the tile from the map and letting inertia or gravity carry you through the tile. The drill requires me to take more control over the digging process.
Just some random thoughts.
Hmm....What about having no change in the player sprite, just some particle effects? Dirt flying, etc. should only take one animation, with several particles, but they behave in the same way, falling in an exponential curve downward over the dirt chunks. The digging itself is also only one process, not three. No idea how big they would all be, though :PThanks for the advice, but that would probably be even bigger. I'll take it under consideration.
Hm. A couple of sprites (3-4?) could show the motion pretty accurately. It would be choppy when starting and stopping though, but it would give more depth to the game IMHO.I'm currently using 3 sprites for animation :P I've also been doing some optimization, and have so far gotten rid of 1,000 bytes of program without losing any features.
You can't use files if you swap in a spare RAM page and take control over the whole calculator, which I do. I can't use very many OS routines this way.What would you want to keep in an external file? You can always cache the location of archived data, and swap those pages manually, e.g.
getExternalData:
; Reads data from an external data file in the archive. The location must be cached.
; Data file must not be larger than 16K.
; Input:
; - HL: Address. If greater than 8000h, will wrap to next page
; - (dataPage): Base page that the external data file resides on
in a, (6)
push af
ld d, (dataPage)
ld a, 080h ; CHANGE FOR APPS!!
cp h
jp nc, dataInArchGoodAddr
ld a, 0C0
add a, h
ld h, a
inc d
dataInArchGoodAddr:
ld a, d
out (6), a ; CHANGE FOR APPS!!
ld d, (hl)
pop af
out (6), a
ld a, d
retEDIT: Yes, I know you're writing in Axe, but Axe can embed assembly code. Also, this can be optimized if you save the page of your application in RAM.
Placeholder? Is that in case there isn't already a map file? Perhaps you could optimize that away with a generator, or force an error if there isn't one, while including one in the final program's zip file.I can't automatically generate the surface map, and in any case, there isn't enough RAM. My optimizations have brought me up to almost 5,000 bytes of space left, so perhaps I can get it smaller.
Sir, did you see my edit from last night? Are you going to put a height limit on negative feet and a terminal velocity?I will eventually put a height limit on negative depth at about -100, and there already is a terminal velocity.
wow... the demo is awesome!You got it right. I'm aware of these issues, and have them fixed in my personal version.
i found some weird stuff though :/
you can go towards the right infinitly and after you go a certain distance you start getting an extra row of stuff above the original surface, and you can't land on it while you can dig it. If you attempt to land on it you seem to just fall through it and land on the second level and unable to fly out since the layer above you remains intact. if you keep flying or digging in ththat direction even further you get bugs in which there are undiggable blocks that look like what was the intended sprite for the drill? O.o
There's a demo? O.OLol, thanks!
EDIT: Nvm I saw on a previous page and this looks incredible! O.O
Only one thing, though, you need to make sure we can't go off the map, like around -666 height :PYeah, I'll add that <.<
You got my hopes up for a second D:Me too. :-\
sorry. And I didn't know he got his calc taken away :(.
Same here :(You got my hopes up for a second D:Me too. :-\
Might as well join the party...Same here :(You got my hopes up for a second D:Me too. :-\
Oh noes!
It seems that one of my source programs (prgmMOTHRSUB, which contains all of the subroutines, including rotating points, drawing the map, etc) is severely corrupted, beyond all hope of restoration. I'll be hunting around for backups, but no promises.