Hayleia, how is one supposed to understand that thing

Hehe
Even when you watch the video and when you have a 1st person view, you still don't know where you are and where you are going

@aeTIos, your coasters are probably really hard to put in Career mode but they are really well designed, and I don't see them in details but it seems to me like they could be seen in real parks

@ordelore, wow, you have a lot of straight turns at high speeds. Are the stats of those rides high ?

I don't particularily like them, it's just that in Career mode, you often have access to wooden, looping and corkscrew roller coasters so I mostly make some of those in Sandbox to be able to re-use them in Career

Also, I made a video of that previous roller coaster
https://www.dropbox.com/s/2u49qa5iz1zmhwa/EpicRollerCoaster.wmv

This looks really cool! I also like the menu, it's really well laid out.

For smooth scrolling the blocks, it looks like there are six possible positions for the blocks. What i would do is have 6 bytes in saferam that can be set to on ($FF or %11111111 in binary) or off ($00). Then, when you scroll the screen left, first shift that byte so that it gets put into the carry then shift the rest of the screen. Repeat until you've scrolled the first 8 rows, then increase to the next byte in saferam and so on until you've scrolled the whole screen. I'm not sure if Axe has bit rotation commands (i don't know how you'd scroll the screen otherwise, though). This way is probably much simpler than drawing a sprite every 8 frames and faster.

Nice job, Axenntio!

Axe doesn't really have bit rotation commands (except /2 and *2) but you still can use the command Asm(). That's in fact exactly what I did to have my pipes and background to scroll smoothly in Flappy Bird.

Lol
And the beige one on the top-right corner isn't that insane
The worst part of it is that it has very good stats for the price it cost o.o
A very good deal when playing a campaign (just don't forget to set the number of circuits to 3 or people will find it a bit short).

So aeTIos forced kindly asked me to post about my vast park, so here it is.
Note that this is just some stupid coaster I made in thirty minutes, not my real park, which is on my sister's laptop -.-

It's true that on my non-CX the speed loss is really bearable, but on CX it's still very slow
On CX, with the old version, you needed 7 seconds to cross the screen with your ship, while on the new version, you need 9 seconds
On non-CX though, you needed not even 4 seconds, and now you need 5 seconds.

edit no, I didn't underclock my CX and no I didn't overclock my non-CX.

Where you like "tl;dr" when you saw my post ? Because I am exactly saying that Copy is better

Axe is not Basic. Here's the source code, in spoiler, for those who wonder why I am saying that.


For example, this Data(96,64)→Pic2 is NOT storing numbers into a variable. This is declaring to the PARSER that the pointer to those numbers who are somewhere in the program whill be called Pic2 until the end of the program.
This means that you don't need your Lbl 1, Goto 2 and caetera. Just put your pic declarations either at the beginning of your program or at the end (after the final Return) or in the middle, it doesn't change anything (putting it at the end helps you reaching the code when you open your program, putting it at the beginning helps you not forgetting what is what and putting it in the middle helps you know which data is used for which part of the code).
But wherever you put it in your source code, they will be put at the end of the compiled executable so your code will be compiled exactly like this one:

---

.TEMPLE
Goto 1

Lbl 2

ClrDraw

Bitmap(0,0,Pic1)
Bitmap(0,0,Pic2)^^r

DispGraph
Repeat getKey(15)
DispGraph^^r
End

Goto 3
Lbl 1
Goto 2
Lbl 3
Return

.black
Data(96,64)->Pic1
[long hex]

.gray
Data(96,64)->Pic2
[long hex]

---

Don't you think now that your Goto 1 then Goto 2 to go back at the beginning are useless ? Same for your Goto 3 ? And even with your original code, the Goto 3 was not so useful, you could have put a Return instead it would have worked too.

Now about your code. You are basically filling the two buffers, so why use Bitmap ? Copy your bytes directly in your buffers instead of wasting space for a routine you use for no big reason. Even worse. Why that DispGraph before the loop with the DispGraph^^r ?

And I would talk about basic optimizations, but this will come later

So yeah, just do this:

---

.TEMPLE
.black
[]->Pic1
[long hex]

.gray
[]->Pic2
[long hex]

.once again, you can put those declarations elsewhere if you want

Copy(Pic1,L6,768)
Copy(Pic2,L3,768)

Repeat getKey(15)
   DispGraph^^r
End
Return
.the Return is not useful if at the end of the program but it's still good to be used to tell the program exactly what we want it to do and not suppose that it will work.

---

And since you are completely replacing all previous content in L6 and L3 by copying and not Bitmapping, you don't even need any ClrDraw.