Heh, you spelled Phoenix wrong   

Nice to see my npc engine style is of use. The hardest parts to get are the conditionals and stuff

Also, if you want a custom input routine, I have one similar to the Pokemon style that you can take a look at if you want. It writes the string to the beginning of L5 and is capped at 8 characters, though that of course could be changed easily

Hmmm...I'll try and think of some unique currency, because you're right, the $ symbol is a bit boring

Also yeah the items have a cap here too (50 of them) but this cap only applies to the amount of different items you have, not how many total so I think it should be fine (ie you can have 200 steaks and you'll have room for 49 more different items )

I am excited since the engine is practically finished now (The only major thing left to program are scrolls; items that let you learn moves) and I have about 1200 bytes left in the app for that. The source is now total 76kb O_o

Well the only way you can tell they are dollars is because I use the dollar symbol. Otherwise, there's absolutely no relation, all the prices I have aren't very realistic at all. I just didn't feel like inventing a name/symbol for the currency, and the $ symbol is all ready and easy to access in the built in ASCII set

<small update>

Ok, I finally finished entering all the data for the items.

There are about 90 items, although I'm thinking that I will add more later.

Also I fixed a bunch of bugs in the enemy generations system that I had missed earlier

I love the third level. And the superspecialawesome mode is...well...super special awesome.

My best score on the 3rd level is like 50k I love the part when the background gets inverted

That's interesting, my raycaster's speed always goes up when you're closer to a wall since then the rays have a shorter distance to travel. Maybe the textures have something to do with it though

Is this a form of tilemapping?
The process would be fairly straightforward: to take the data and decide how to draw which tile you could just do
Pt-On(X, Y, {index+GDB1}*8+Pic0)

or something, where your tiles are defined consecutively starting at Pic0.

Is this what you're talking about?

Now, I know that everyone's all like: blargh imma wanting some of that multipage app goodness, and Quigibo's like....not practical.

If I understand correctly, it's not that compiling a multipage app is difficult because it's large, but it's that creating the instructions to swap pages and that knowing when and where to swap pages in an arbitrary program makes it difficult.

Now, simplifying, the problem would be would that the parser doesn't have enough information (that only the programmer would know) to accurately create the multipage app.

So my idea was, to have integrate a compiler command to indicate the different pages :| There would probably two commands, one to call the 2nd page and one that is some kind of modification to the #include (prgmXXX) function, where that program would be parsed into the 2nd page. Then, in the app's code, when the program needs to swap pages, there would just be some command in the 'mother app' to switch pages. For example, if you wanted to mix a battle engine (in prgmBATTLE) with a tilemapper, the code might look like this:
blah blah blah tilemapper code
<when a battle occurs>
instruction to swap to 2nd page of app
more code blah
...

instruction to parse prgmBATTLE as the second page of the app

Basically, what this could do would be to enable "packaging" of a second app together with the first app, sort of like what Builderboy's virtual-page program does, but only with real app pages. While this method would in no way be close to producing the flexibility of a real asm-programmed multipage app, I figure that this, well, it's better than what we have right now . It would require the programmer to make sure that his pages can run completely independently of eachother (no subroutines or anything), but that's a small price to pay.

Thoughts? Is this even possible?