Only when Sorunome's bots are down tho

This also means something I thought was possible is MORE possible!!!

A ti-84 emu can be made easily now because the screen res can be made compatible!

yeah, I can convert them!

Thanks!

So... line drawing's done! I didn't do it Hayleia's way or Shimbs's way (I couldn't think of a way to implement them in my current source), but I did it with the line( command (and it is pretty good, if I may say so myself )

Thanks for the support!

On a side note, I might use full (only when drawing the map) to keep things smooth when transitioning (not implemented yet)

And now: *Drumroll*

SCREENIE!!!



Downloads for PIMAP, VVVVVVSRC, and VVVVVV are attached

Well, if you look at ant of my other posts, you'll see me keep asking if someone can help me >.<

So let's say it again : there indeed is a problem in the actual game engine (by that I mean not in the menu). The program has different behaviors depending on the execution method, and always occuring after the exit : compiled as an app, it leaves weird characters on the homescreen ; compiled in Noshell, it messes with the random-related functions and makes them display huge numbers (it starts at 10³² and slowly go back to their initial range as you run it again and again), and moreover it displays a random ERROR:something 1 time out of 3 ; and compiled for MirageOS, it constantly crashes.

I can't release the actual source (I'm on a phone) but I have them on my computer, so I'll upload them tomorrow (it's 11:06 pm here).

I haven't looked at your source (I don't see the latest source out, but I think I know what a quickfix is... (Might not work in the long run, but it might work in the long run))

If you use files for accessing external vars:

Do you end your program with ClrHome? I think I heard somewhere that when you use files, random stuffs happen if you don't use ClrHome at the end...

Err... maybe it's with all external vars... not sure... but try that and tell me if it works

I think I have a solution!

In my map-creating program could do the sorting stuffs for me and I could use separate sprites!

I was trying to think of a way to use separate sprites without having to redo my maps and keep track of more tile types, and I think I got it!

In the prog that makes the map appvar (the prog is actually a HUGE app with all the data), I can make a routine that converts the stuffs to the different types of sprites needed (16 different combinations of outlines, if my calculation is right) and not slow down my main program with an algorithm. (I'm going to borrow some of Hayleia's code for this).

On a side note: I'm sorry for using the caps and stuff... I use caps as a stressor instead of italics... I don't mean yelling unless the entire sentence is in all caps.

I meant that the byte WAS 0, not 0 bytes...

I misunderstood your point... I think I'll use a line-drawing command instead of making a bunch of different sprites, though...

Actually, for the example above, I tried without the inside corners and it doesn't necessarily look bad, so you could just not use them and you would need even fewer tiles (I think about 15 fewer tiles)

I don't get where you're going...

But if it is about size/speed:

That won't make a difference in the size/speed of the map/game because the map is a set # of bytes... 0 still is a tile, just a blank one...