CodeWalrus

Wal-Rush! CE is a port of JWinslow23's PC game called Wal-Rush!, which he made for CodeWalrus Contest II. He also made an Atari 2600 version and now I have ported the game to the TI-83 Premium CE and TI-84 Plus CE calculators! In this game, you control Walrii, the CodeWalrus mascot, in its winged form, and must fly your way through various obstacles while eating floating fishes. :3=

The game is written in hybrid TI-BASIC with the help of an ASM library called Sprites, by grosged, which can be downloaded at https://tiplanet.org/forum/archives_voir.php?id=539203 . The game originally used CE Textlib, by DrDnar, found at http://www.ticalc.org/archives/files/fileinfo/465/46522.html , and circumvents CE Textlib rectangle command limitations in every way possible, allowing full-screen game play with graphics that are reminiscent of the Atari 2600 days. But the switch to Sprites allowed better graphics and much faster speed. Both versions are included in the ZIP file below. Unlike the original games, this calculator port is in color instead of grayscale and there is an extra obstacle to avoid.

NOTE: This game will NOT run on the TI-84 Plus C Silver Edition!

(https://img.ourl.ca/walrush21.gif) (https://img.ourl.ca/walrush22.gif)
(Click here for an animated screenshot) (https://tiplanet.org/modules/archives/captures/1465360376walrush20.gif)

[spoiler="Click for older screenshots"](http://img.ourl.ca/walrush2-1.gif) (http://img.ourl.ca/walrush1.gif)
(Click here for an older animated screenshot) (http://img.ourl.ca/walrush.gif)[/spoiler]

[spoiler=Original post follows]@Dudeman313 's topic earlier gave me the idea to port Wal-Rush to the TI-84 Plus CE using only TI-BASIC and CE Textlib. Unlike @JWinslow23 's original game, I decided to use colors, like in the Walrii flight animation his game was inspired from.

CE Textlib lacks sprites support. However, it allows chaining commands, which allowed me to display multiple rectangles to form large, pixelated graphics and a 8x5 :walrii: sprite (based on JWinslow's 8x8 Atari sprite) using just 1 Asm(prgmTEXTLIB) command:

(https://img.ourl.ca/walrushce.gif)

1→A
0→B
1→E
0→R
0→O
0→P
{1,33,0,1,4,27,18,33,4,1,8,27,14,33,12,1,1,27,18
Asm(prgmTEXTLIB
While B<10
{33,4,1,1,A,14,33,4,A+1,1,6,18,33,4,A+8,1,7,14,33,4,A+14,1,6,18,33,0,19,4,8,18,33,5,19,7,8,14,33,12,19,1,8,18,33,0+B,20,1,2,20,33,0+B,23,1,2,20,33,1+B,21,1,1,20,33,1+B,20,1,1,10,33,1+B,23,1,1,10,33,1+B,24,1,1,20,33,2+B,19,2,8,23,33,2+B,20,2,1,20,33,2+B,22,2,1,20,33,4+B,19,1,1,23,33,4+B,21,1,2,23,33,4+B,24,1,2,23,33,R,O,2,2,11,33,R,O-2,2,2,14+4(R<4
Asm(prgmTEXTLIB
A+1→A
If A>13:1→A
getKey→Z
If Z=21:⁻3→E
E+1→E
If E>2:2→E
B+E→B
If B<0:0→B
O+2→O
If O>25:Then
1→O
P+1→P
randInt(0,9→R
End
End
For(Z,10,24
{33,0,1,4,27,Z,33,4,1,8,27,Z,33,12,1,1,27,Z,11
Asm(prgmTEXTLIB
End
ClrHome
Disp "Score:
Output(1,8,P

Because I tried to keep speed to maximum and am circumventing some CE Textlib limitations to draw stuff outside its 26x10 boundaries, I cannot guarantee 100% that this game will be stable, so I suggest that you back up first before trying or use an emulator. Also, various display glitches will occur.

It isn't complete yet, so obstacles don't work yet and I'm unsure if I will add the calculator power-up, but I was bored and I thought it would be funny to see how far CE Textlib limits could be pushed by abusing its rectangle display feature.[/spoiler]

You need Sprites by grosged from https://tiplanet.org/forum/archives_voir.php?id=539203 to play this game.  The game download is attached to this post below.

http://www.ticalc.org/archives/files/fileinfo/466/46696.html

That looks very Atari2600 - like. Love it ;D

Thanks. I am surprised at the speed so far. Hospefully I can make it faster even after adding collision with objects.

Cool! Just seeing this now.  O.O

By the way, the following screenshot shows why a CSE is not recommended for this game:

(https://img.ourl.ca/walrushcse.gif)

I just remembered that there was a CSE version of Textlib, so I was curious about how much slower the game ran, and it was abysmal O.O

Here's the CE screenshot from my earlier post as a comparison:

(https://img.ourl.ca/walrushce.gif)

Most CE BASIC games run 21% faster, but when they involve redrawing the entire screen with ASM libs, the increase is much higher (sometimes 1000% faster)

Quote from: DJ Omnimaga on March 12, 2016, 05:52:03 AM
@Dudeman313 's topic earlier gave me the idea to port Wal-Rush to the TI-84 Plus CE using only TI-BASIC and CE Textlib. Unlike @JWinslow23 's original game, I decided to use colors, like in the Walrii flight animation his game was inspired from.

CE Textlib lacks sprites support. However, it allows chaining commands, which allowed me to display multiple rectangles to form large, pixelated graphics and a 8x5 :walrii: sprite (based on JWinslow's 8x8 Atari sprite) using just 1 Asm(prgmTEXTLIB) command:

(https://img.ourl.ca/walrushce.gif)

Code Select Expand

1→A
0→B
1→E
0→R
0→O
0→P
{1,33,0,1,4,27,18,33,4,1,8,27,14,33,12,1,1,27,18
Asm(prgmTEXTLIB
While B<10
{33,4,1,1,A,14,33,4,A+1,1,6,18,33,4,A+8,1,7,14,33,4,A+14,1,6,18,33,0,19,4,8,18,33,5,19,7,8,14,33,12,19,1,8,18,33,0+B,20,1,2,20,33,0+B,23,1,2,20,33,1+B,21,1,1,20,33,1+B,20,1,1,10,33,1+B,23,1,1,10,33,1+B,24,1,1,20,33,2+B,19,2,8,23,33,2+B,20,2,1,20,33,2+B,22,2,1,20,33,4+B,19,1,1,23,33,4+B,21,1,2,23,33,4+B,24,1,2,23,33,R,O,2,2,11,33,R,O-2,2,2,14+4(R<4
Asm(prgmTEXTLIB
A+1→A
If A>13:1→A
getKey→Z
If Z=21:⁻3→E
E+1→E
If E>2:2→E
B+E→B
If B<0:0→B
O+2→O
If O>25:Then
1→O
P+1→P
randInt(0,9→R
End
End
For(Z,10,24
{33,0,1,4,27,Z,33,4,1,8,27,Z,33,12,1,1,27,Z,11
Asm(prgmTEXTLIB
End
ClrHome
Disp "Score:
Output(1,8,P

Because I tried to keep speed to maximum and am circumventing some CE Textlib limitations to draw stuff outside its 26x10 boundaries, I cannot guarantee 100% that this game will be stable, so I suggest that you back up first before trying or use an emulator. Also, various display glitches will occur. 

When you said "various display glitches" you weren't kidding, but the speed makes up for it. O.O

Otherwise, it's pretty entertaining. :P

Yeah, the glitches are because I went the Atari 2600 route of not bothering to fix some of the less noticeable/annoying ones just to keep the speed up and the game full-screen. You also have to keep in mind that Textlib was not intended to be used outside the boundaries of the Output() command. Hence my comment about backing up first, because I don't know if it can cause crashes. It seems like it doesn't, but an expert would need to examine the debugger of an emulator while the game is running to see if any important RAM areas are being erased by my "misuse" of CE Textlib rectangle command.

But there's one glitch that annoys me: It's the one causing a weird rectangle to appear in the middle.

Where in the middle? Do you mean in the background, where one of the rectangles scrolls instead of staying still?

This is what I mean:

(http://img.codewalr.us/this.png)

That reminds me, I should poke @tr1p1ea about adding the ability to chain rectangle commands in xLIBC (eg real(7,9,X,Y,W,H,C,X,Y,W,H,C,X,Y,W,H,C,X,Y,W,H,C,X,Y,W,H,C,X,Y,W,H,C,X,Y,W,H,C,X,Y,W,H,C,X,Y,W,H,C) (this would draw multiple rectangles in just 1 real command, like how we can draw multiple sprites from one command). THis could be handy for drawing window boxes and doing art that doesn't take much space

That's what I thought.
I ran the same code you used for that background without the rest of the game, and it was stable.

Also, I think that'd be a useful feature.

What I noticed is that the glitch happens when the red blocks reach the right of the screen.

I saw that too. Also, sometimes, the back of the :walrii: leaves a grey line in that same area.

Yeah, that's due to how scrolling works. I might change the scrolling anyway. My goal is to keep screen updates to a minimum each frame.

Okay.

I might end up making a Textlib version of
my text RPG.

Good luck!

Progress update:

-Changed mountain colors from green to turquoise (apparently, that's possible)
-Redid parallax scrolling to reduce screen updates and thus, gain a bit of speed
-Made Walrii in fewer rectangles (slightly slower but drawing less rectangles offsets that, plus it's smaller)
-Now Walrii can move left and right like in the original game
-Made spikes smaller and fixed erasing bug at the right of the screen (introduced by previous feature)
-Fixed weird vertical lines left behind Walrii in the mountains.

(https://img.ourl.ca/walrushce2.gif)

TODO
-I need to figure out a way to make Walrii erasing so that it doesn't have to update an entire 4x8 and 7x8 screen chunks (unless doing so is so complex that it actually slows the game down)
-Collision detection with spikes
-Fish item (it seems the calc isn't in the Atari game so I guess I can do away with it). Fishes would give an extra 100 pts.
-See if glitchiness in the middle of the screen can be alleviated without severe slowdowns. I could probably outdo the parallax edits I made in this update, though, if adding the next features doesn't cause slowdowns.
-Title screen?

Looking good, and btw your rectangle request should be pretty easy to implement. Be sure to remind me in a couple of weeks when I'm (hopefully) up to porting the drawshape commands :).

Thanks tr1p1ea. ANd glad to hear. Would it be hard to implement? You should maybe make an xLIBCE features/showcase brainstorming topic @tr1p1ea in case some of our non-Cemetechians have ideas or that I forget :P.


I found some weird oddities about CE Textlib boundary circumvention.
-For example, if a rectangle overflows at the bottom of the screen, it seems to be shifted 1 pixel to the left in its entirety. This is why there was a gray trail left behind the walrus sometimes.
-Also, the X/Y values seems to be 1 bit unsigned, or at least 256 acts like 0 and so on.
-16 colors are supported instead of 15, turquoise being color 25 (I assume it's the turquoise from home screen highlighted text when scrolling up in entry history?)
-Drawing stuff off-screen causes it to loop back, but shifted by a few pixels. This could be handy for some advanced graphics, but probably not that practical.
-I have yet to run into any odd calculator behavior/crashes following the abuse of CE Textlib rectangle limitations.

Quote from: DJ Omnimaga on March 16, 2016, 08:29:32 AM
Progress update:

-Changed mountain colors from green to turquoise (apparently, that's possible)
-Redid parallax scrolling to reduce screen updates and thus, gain a bit of speed
-Made Walrii in fewer rectangles (slightly slower but drawing less rectangles offsets that, plus it's smaller)
-Now Walrii can move left and right like in the original game
-Made spikes smaller and fixed erasing bug at the right of the screen (introduced by previous feature)
-Fixed weird vertical lines left behind Walrii in the mountains.

(https://img.ourl.ca/walrushce2.gif)

TODO
-I need to figure out a way to make Walrii erasing so that it doesn't have to update an entire 4x8 and 7x8 screen chunks (unless doing so is so complex that it actually slows the game down)
-Collision detection with spikes
-Fish item (it seems the calc isn't in the Atari game so I guess I can do away with it). Fishes would give an extra 100 pts.
-See if glitchiness in the middle of the screen can be alleviated without severe slowdowns. I could probably outdo the parallax edits I made in this update, though, if adding the next features doesn't cause slowdowns.
-Title screen?

Updates! :D
I can make a nice title screen if you want me too. :)

I should be fine since the title screen will most likely be simple, but thanks anyway :)

Something I wonder is: What TI-BASIC command usually redraws the status bar at the top of the screen? I thought that Disp/Dispgraph and Clrhome did, but it appears not, unless it's caused by CE Textlib.

I thought it might be those too, because the more you refresh your screen, the more it reappear.
Maybe you should try covering it and then deleting Textlib to see if it will still redraw.

Nah, I haven't figured out how to make it redraw inside the program until I quit. It might be some setting in CE Textlib, though. In xLIBC when the busy indicator was disabled in 160x240 mode it also prevented the bar from being redrawn and there was an option when switching back to 320x240 that allowed you to redraw it upon switching.


Also here is the title screen :D

(https://img.ourl.ca/titlescreenforwalrushce.gif)

I wasn't asking that; I meant that what would happen if you covered the bar in a program, deleted Textlib after exiting the program, and then looked to see if the bar would still be redrawn?

The title screen is awesome! XD
But IMO, if "Walrush CE" was 1 row taller though, I'd be even better.

Oh, I wouldn't need to delete TEXTLIB to redraw the bar. It eventually redraws itself when the program is finished, such as when I press the graph key.

Also thanks. I didn't make it longer since I used lowercase, but I,ll see what I can do.

@Dudeman313 on a side note I implemented your title screen change idea and it looked better than I thought. I also made the text underlined. On the emulator the top looks a bit dark, but on a real calculator it's perfect:

(https://img.ourl.ca/walrush.png)

Awesome! :thumbsup:

Thanks. :D By the way development on this might be slower as I experiment with the tilemapper. I don't plan to implement the tilemapper in this game for speed reasons, but I might see if I can reduce the space between each Walrii blocks, so that I can make it smaller (since it's so big right now >.<)

Would drawing the smaller rectangles help you at all?

I'll most likely do that for some of the Walrii blocks, such as the legs or the eyes (so they're a bit less tall).

Of course the title will be drawn with smaller blocks too.

I'd like to see that. :)

Ok so for the next update on this, I am contemplating making Walrii much smaller. I don't know if it will use 4*4 blocks because of slanted block display limitations, but it's entirely possible. I would just like Walrii to not fill half of the screen and maybe I could use something closer in style to @JWinslow23 Atari sprite that way.

Okay. :)
Speed is always an issue, though, so keep that in mind.

It depends. Making the sprite smaller would increase the speed, but adding more rectangles would decrease it.

So you might even end up with a smaller sprite that has the same speed as the larger one, but with more details?

It depends how speed will go. If I notice a significant speed increase then yes I might add more details.

I could also add more details to other stuff, such as background hills or the spikes. I don't want to use ASCII characters because TI text routines are slow as garbage (especially on the home screen).

Major update! :D

-Walrii sprite has been downscaled using the extra CE Textlib stuff I learned after starting this project.
-Spikes now move faster and no longer flickers
-Walrii gravity has been increased (he starts falling down earlier too)
-Brand new title screen! Text is less spaced out so that I could fit an exclamation mark and CE in the title. @JWinslow23 will be happy about the ! :P


(https://img.ourl.ca/walruses2.gif)

:walrii:

Oh, trust me, I'm actually very happy with the "!". For an extra challenge, though, try to design a convincing "‽".

/me runs

All jokes aside, this looks WONDERFUL!

Lol I don't think it would be that hard, but it would require modifying the title display routine :P

Thanks! Also I am sticking to single rectangles for spikes because I want to finish the entire game and ensure that speed remains good. I will only design spike sprites if it doesn't slow the game down too much, same for fishes (if any). Ideally, both of those should be restricted to 3 rectangles each

Thingies are weird and stuff. :P

I don't get what you mean by your post ???

Don't you worry, you don't have to. That's the point. :P

Well, have you seen First Fantasy II map loading? 27 rectangles takes 0.3 seconds to render, hence why I try to keep the amount lower than that in Wal-Rush! CE. <_<

Not to mention the maximum that can be drawn in 1 command is 42 anyway (the answer to life, universe and everything)

Quote from: DJ Omnimaga on April 13, 2016, 07:01:28 PM
Well, have you seen First Fantasy II map loading? 27 rectangles takes 0.3 seconds to render, hence why I try to keep the amount lower than that in Wal-Rush! CE. <_<

Not to mention the maximum that can be drawn in 1 command is 42 anyway (the answer to life, universe and everything)

I get it, I get it. It's absolutely fine, as long as it doesn't take 24 hours to render 1 frame :P

Indeed. In FFII this is why the entire map is only rendered once entering the dungeon. When you switch to a new room, only the 4 exits are updated. Else it would take 8 seconds to load every room.


Also here are some 3-rectangle fish/spike ideas if I was to improve the other sprite:

(http://img.codewalr.us/fishspikes.png)

The spikes would pretty much be a recolored fish sprite with one of the rectangle being the same color as the background. :P

Quote from: DJ Omnimaga on April 13, 2016, 07:08:32 PM
Indeed. In FFII this is why the entire map is only rendered once entering the dungeon. When you switch to a new room, only the 4 exits are updated. Else it would take 8 seconds to load every room.


Also here are some 3-rectangle fish/spike ideas if I was to improve the other sprite:

(http://img.codewalr.us/fishspikes.png)

The spikes would pretty much be a recolored fish sprite with one of the rectangle being the same color as the background. :P

I was thinking something TOTALLY different for the spike (one for "body", and two perpendicular "spikes" going through the center, creating 4 spikey thingies emanating from a thing), but second row is good.

Wow. I totally missed that major update. Cool! The game looks a whole lot neater now. I really like the title screen! :)

Thanks a lot. I made the title screen gradient by drawing 3 rectangles per gradients at different horizontal offsets in some cases (yes, horizontal). The grass was made using a technique similar to what I explained in the other thread too.

Do the obstacles work now?

Not yet, but I improved the speed and reduced flicker by replacing the massive half-screen rectangles that were used to erase Walrii. I now use an extra variable but at least the sprite is now erased with a much smaller rectangle.

The score now also shows up at the bottom of the screen

Oh, okay. :)

So a little update: Although the game is now over 100 bytes larger, the sky in the title screen is now drawn instantly. Rather than a for loop with a big list full of conditionals and an useless iteration, I just went with a larger list, but with less conditional, so while it's larger, the size increase isn't that bad. Now the only slow part is the title text.

Quote from: JWinslow23 on April 13, 2016, 07:11:12 PM

Quote from: DJ Omnimaga on April 13, 2016, 07:08:32 PM
Indeed. In FFII this is why the entire map is only rendered once entering the dungeon. When you switch to a new room, only the 4 exits are updated. Else it would take 8 seconds to load every room.


Also here are some 3-rectangle fish/spike ideas if I was to improve the other sprite:

(http://img.codewalr.us/fishspikes.png)

The spikes would pretty much be a recolored fish sprite with one of the rectangle being the same color as the background. :P

I was thinking something TOTALLY different for the spike (one for "body", and two perpendicular "spikes" going through the center, creating 4 spikey thingies emanating from a thing), but second row is good.

My goal there was to re-use the same sprite for both the fish and the spikes, drawn with 3 rectangles. The spike would basically be a teal/cyan rectangle (which is invisible against the background) with the two others being red. Also sorry I missed your post @JWinslow23 for some reasons. :P

Improvements! ;D

Good news: The game is finally complete! :D

New feature additions:
-Collision detection for fishes and deadly obstacles
-Fishes gives 10 points
-Along with spikes, there are now mines as well. Mines will chase you so they are much harder to avoid.
-Highscores support
-The death animation has been added and now looks similar to the Atari 2600 version in style.
-You can now exit the game with CLEAR from the title screen or during the game.

(http://img.ourl.ca/walrush2-1.gif) (http://img.ourl.ca/walrush1.gif)
(http://img.ourl.ca/walrush.gif)

You need CE Textlib from http://www.ticalc.org/archives/files/fileinfo/465/46522.html to play this game.  The game download is attached below:

http://www.ticalc.org/archives/files/fileinfo/466/46696.html

Awesome! My only complaint is that the controls feel a bit stiff (can only press one button at a time), but that's a TI-BASIC limitation, so I give it a pass. Congratulations!

Oh, and how do you get a crab off of a polar bear? Just wondering.

WOW! How did I miss that post? It looks awesome, especially with the score bar. :D
Any Easter Eggs?

Quote from: JWinslow23 on April 20, 2016, 09:46:57 PM
Oh, and how do you get a crab off of a polar bear? Just wondering.

You don't. You wait for the polar bear to eventually find some way of killing the crab because of its annoyingness.

Also, there's a random question thread, under Randomness. Go there with your random questions in the future. :)

Thanks guys. And yeah @JWinslow23 I don't understand why TI still insists on allowing 1 keypress at a time in most of their newer languages. I mean, on the Casio PRIZM, the TI-89 and the HP Prime we can press multiple keys at once, but in Z80/ez80 BASIC and Nspire Lua we can't. Go figure. ???


And @Dudeman313 nope there are no easter eggs, although there is a small display bug that I was too lazy to fix: When the fishes appear in the top most row, they look like spikes but blue, This is because of the hackish ways I used to display properly aligned rectangles on the 4x4 grid, which won't show up if they are displayed at the very top of the screen and not at multiples of 12. <_<

Oh, okay. :)

And the key thing is annoying on TI's part.  <_<
Is there anyway at all to make multiple key-presses allowed?

Wow, this is pretty cool! I didn't think that Textlib would be able to handle this kind of displaying!

I know, right?
Someone's got to ask if the Dr. knew about all this stuff.

Quote from: Dudeman313 on April 20, 2016, 10:47:46 PM
Oh, okay. :)

And the key thing is annoying on TI's part.  <_<
Is there anyway at all to make multiple key-presses allowed?

You need xLIBCE, ASM or C for that, or someone would need to make a standalone library that adds multi-keypress support to BASIC.

Quote from: Unicorn on April 21, 2016, 06:37:08 AM
Wow, this is pretty cool! I didn't think that Textlib would be able to handle this kind of displaying!

Yeah me neither. What happened is that a few months ago I remembered that CE Textlib supported chained commands, so I figured I would make a 26x10 resolution Wal-Rush clone using multiple rectangles, but I forgot that rect started at 0, not 1, and somehow it still drew my rectangle anyway (overlaping on the gray status bar). Later I discovered that drawing rectangles far into the screen wrapped around on the other side, then I discovered that when wrapping around the rectangle position or size were not exactly the same as when drawn properly. This is how I finally discovered that CE Textlib games could actually be 27x59 or something.

I knew that 80x59 was also possible, but some rectangles were offset by 1 or 2 pixels vertically, and more recently I finally realized that wrapping enough enough times would display the misaligned rectangles exactly 4 pixels below, so all I had to do afterwards was move that rectangle up. The drawback with that trick is that they can't be drawn in the first rows, so technically full-res CE Textlib games are 80x57 or so.

Quote from: Dudeman313 on April 21, 2016, 10:45:45 AM
I know, right?
Someone's got to ask if the Dr. knew about all this stuff.

If you mean DrDnar, the author of CE Textlib, then I don't know if he's aware of this. He might be aware about if using such trick can screw up your calculator RAM data but so far I have never encountered any crash nor any other issues while using CE Textlib tricks. I hope he doesn't patch all those exploits once he discovers, though. :P

Quote from: DJ Omnimaga on April 21, 2016, 02:07:05 PM

Quote from: Dudeman313 on April 21, 2016, 10:45:45 AM
I know, right?
Someone's got to ask if the Dr. knew about all this stuff.

If you mean DrDnar, the author of CE Textlib, then I don't know if he's aware of this. He might be aware about if using such trick can screw up your calculator RAM data but so far I have never encountered any crash nor any other issues while using CE Textlib tricks. I hope he doesn't patch all those exploits once he discovers, though. :P

Yeah, me too. I doubt he'd go all Nintendo/TI on us, though.

Yeah true. That's unless those tricks are dangerous for the calc, but since I never ran into issues, I doubt it. The only concern i have is when drawing outside the top or bottom of the screen, as it won't wrap around right away, but someone who knows more about the calc memory and the LCD memory would probably be able to investigate. Maybe @MateoConLechuga @Adriweb or @critor might know?

Well, corruptions here and there, and eventually it can crash/ram clear/reboot, but that's pretty much it.
Nothing to really worry about if you have backups.

But that's unlikely, right?

Quote from: Adriweb on April 21, 2016, 08:04:09 PM
Well, corruptions here and there, and eventually it can crash/ram clear/reboot, but that's pretty much it.
Nothing to really worry about if you have backups.

Do you mean it's guaranteed to cause corruptions, or a possibility?

No, not guaranteed, as I've often done that without actual trouble, but it happens.
Anyway, stay between D40000h and D65800h :P

Now if only I knew what that was :P

Care to explain, @Adriweb ? :P

Well, D40000h (or 0xD40000) is the [MMIO] address of the start of the VRAM (Where the LCD will display the data from, by default).
And 0xD65800 is the end of it, because we have 320x240x2 bytes (2 because 16bpp), which is 153600 bytes (== 0x25800).

(More info: http://wikiti.brandonw.net/index.php?title=Category:84PCE:RAM:By_Address)

And now I understand.  :thumbsup:

Quote from: Adriweb on April 22, 2016, 06:33:51 PM
Well, D40000h (or 0xD40000) is the [MMIO] address of the start of the VRAM (Where the LCD will display the data from, by default).
And 0xD65800 is the end of it, because we have 320x240x2 bytes (2 because 16bpp), which is 153600 bytes (== 0x25800).

(More info: http://wikiti.brandonw.net/index.php?title=Category:84PCE:RAM:By_Address)

What I find interesting is that when I draw outside the screen with CE Textlib, it wraps on the other side automatically. It's almost like if DrDnar expected that some people might do it by accident and rather than disallowing drawing outside the screen outright, he just made graphics loop on the other side. Unless I'M missing something? In any case, I guess it was a welcome move from him. :P


THe following screenshot doesn't make things justice because of how flickery it is, but you should still have an idea of what I mean.
(https://img.ourl.ca/txtlibrct.gif)
EDIT: Here's a better screenshot but it's close to 1 MB large: https://img.ourl.ca/txtlibrct-1.gif

Ah. That's cool.  :)

I wonder what games might be able to use this trick...

This one already does lol. But FFII is another example.

Oh, okay.

You could also make a pretty cool looking aquarium with that trick. :P

Well, if you mean fishes going left and right, I would need to make fishes loop back from 26 to 1 because they would be shifted one pixel below once looping horizontally.

Oh.  :-|
So what kind of program might directly use that trick?
And has anyone actually thought of using Textlib for a Text Viewer?

The trick is only a matter of using an extra variable and once A reaches 26 you set it to 1.

And a text viewer would be feasible but text would probably be a bit large. :P

Quote from: DJ Omnimaga on April 23, 2016, 03:45:35 AMWhat I find interesting is that when I draw outside the screen with CE Textlib, it wraps on the other side automatically. It's almost like if DrDnar expected that some people might do it by accident and rather than disallowing drawing outside the screen outright, he just made graphics loop on the other side. Unless I'M missing something? In any case, I guess it was a welcome move from him. :P

THe following screenshot doesn't make things justice because of how flickery it is, but you should still have an idea of what I mean.
(https://img.ourl.ca/txtlibrct.gif)

This is because of the layout of RAM; it's sequential. It doesn't wrap at all, that's just a lack of clipping. It will always be off by one pixel height wise on the opposing side because it is looking at the next address.

So basically, if I draw something far enough, it will draw it at the same spot but at different RAM addresses? I'M unsure if I get what you mean right.

By the way, one example where I can draw two rectangles at the same location would be {33,12,1,1,1,10:Asm(prgmTEXTLIB and {33,780,1,1,1,10:Asm(prgmTEXTLIB. (there's no offset by 1 pixel or anything in that case)

By the way, I just tried this on a real calculator with almost all my RAM free and not many sub-programs and this ran blazing fast (6 FPS). This is because using Asm(prgmNAME) searches the VAT for the lib. So if you wamt to enjoy this game to its full potential, then I recommend you play this game with as few calc files as possible installed, preferably nothing else besides Textlib and the game.

(https://img.ourl.ca/walrushsprites.gif)


I'm doing a new version of this game that uses @grosged Sprites v3.2 library. Only the title screen is done so far, though.

So I finally switched to actual sprites and there was a massive frame rate increase *.*

(https://img.ourl.ca/walrusprites.gif)

I had to slow the game down a bit. The funny thing is that since I use low-resolution sprites (the :walrii: is from JWinslow23's Atari game, but 8x8 instead of 8x9), the game ended up being smaller than the rectangle version showcased above.

It's beautiful! *.*

Thanks. What needs to be fixed next is the collision, because since I had to slow movement down it broke stuff and I need to make the collision accurate again. Currently it's very hard to hit anything <_<


EDIT: Collision detection has finally been fixed and a death animation was added:

(https://img.ourl.ca/walrushdeath.gif)

Sorry for the double-post, but here is version 2.0 of Wal-Rush! CE!

(https://tiplanet.org/modules/archives/captures/1465360376walrush20.gif) (https://img.ourl.ca/walrush21.gif) (https://img.ourl.ca/walrush22.gif)

https://tiplanet.org/forum/archives_voir.php?id=496532

Yeah !! Good job, DJ Omnimaga  ;D
I'm glad that bugs seem to belong to the past  :D

I still had the green square bug in v3.3 sadly, so I had to re-add the dummy sprite for the fish to work D:

Hmmm, I try to understand why... maybe the beginning of the memory area (where sprite 000 is stored)  is not safe enough.
You wrote you need to define a dummy 7*3 sprite, zoomed 4...Perhaps by moving this memory area 338 bytes away, It may be okay !  9_9
Would you try a beta version ?

EDIT : please try again (I've just updated the version 3.3 , including the little modification ;) )

Yeah I don't mind trying a beta version.

I tried the trick you posted in the other topic (starting at sprite 000) and to no avail. The square still appears. You could always try moving the sprite data 338 bytes further or so to see what happens.

I've just included this little modification , please download again this updated version 3.3 ;)
ah, dinnertime , tell me... bye !

It seems to work, now :D. At least, it seems to work before and after I do a RAM clear, so I guess things are good now. Here's my new code:

Asm(prgmSETTINGS
0:Asm(prgmCLSCREEN
Goto 0
Lbl S
"001,75,450000004555000444455544440004000000
Asm(prgmSPRITE
"002,75,400606006006006066466060060060060600
Asm(prgmSPRITE
"003,C5,7000099990000099988889999988877778888877700007777700000000000
Asm(prgmSPRITE
"004,88,40330330012212210112112103333333332323333323233333333333330330330
Asm(prgmSPRITE
End
Lbl 0
{20,25,255,148,224,227,0,12,4,34,231,129
Asm(prgmPALETTE
1→dim(ʟWALRS
"000,75,410011101011121111111110111111001110
Asm(prgmSPRITE
For(Z,⁻1,0
If Z
Goto S
End
"005,55,70000000000000000000000000
Asm(prgmSPRITE
"006,88,3A33A33AA1221221A1121121A333333333232333332323333333333333A33A33A
Asm(prgmSPRITE
"007,Y5,4BBB666BBB6666BBBBBB6BBB66666BBBBBB44466644464446664446444666664446665556665556555666555655565556555555AAAAAAAAA6AAA666AAA6AAA66666AAA6662226662226666222222622266666222666
Asm(prgmSPRITE
"008,Y5,46666BBB666BBB6BBBBBB6BBB6666666BBB44464446664446444666644466666664446666555666555655555565555556666555AAA6AAA666AAA6666AAA6AAA666AAA66662226666222666622222262226662226222
Asm(prgmSPRITE
"009,75,4BBB6BBB46664665666555A666A662226222
Asm(prgmSPRITE
{224,225,232,233,226,231,228,229,230,227
Asm(prgmPALETTE
"010,75,410011101011121111111110111111001110
Asm(prgmSPRITE
For(Z,⁻1,0
If Z
Goto S
End
{227,230,229,228,231,226,233,232,225,224
Asm(prgmPALETTE
"011,75,410011101011121111111110111111001110
Asm(prgmSPRITE
For(Z,⁻1,0
If Z
Goto S
End
{0,0,320,80,0,0,77,320,8,16,0,78,320,1,0,0,85,320,8,25,0,86,320,1,16,0,93,320,8,29,0,94,320,1,25,0,101,320,8,14,0,102,320,1,29,0,109,320,61,231,0,110,320,1,14,0,170,320,71,5,2,41,316,4,129
Asm(prgmCLSCREEN
{6,146,111,7,2,17,8,138,17,9,290,17
Asm(prgmSPRITE
For(A,0,288,24
{10+A,168,1,4,16,18+A,170,4,1,231,26+A,169,4,4,14
Asm(prgmCLSCREEN
End
{89,52,14,0,1,2
Asm(prgmPRINT
"A GAME OF WALRUSES
Asm(prgmPRINT
{12,179,0,5
Asm(prgmPRINT
"PC an\d Atari 2600 game by JWinslow23
Asm(prgmPRINT
{20,199
Asm(prgmPRINT
"TI-84 Plus CE remake by DJ Omnimaga
Asm(prgmPRINT
{48,219
Asm(prgmPRINT
"(C)2016, https://codewalr.us
Asm(prgmPRINT
{114,146,0,231
Asm(prgmPRINT
"Highscore:
Asm(prgmPRINT
{202,146
Asm(prgmPRINT
ʟWALRS(1
Asm(prgmPRINT
0getKey
Repeat Z
getKey→Z
End
If Z=45:Then
Asm(prgmBACKHOME
ClrHome
DelVar L₁Return
End
While 1
1→A
0→B
0→I
288→C
288→D
1→E
10→R
0→O
0→P
288→F
0→G
1→M
{0,0,320,220,20,0,220,320,20,0
Asm(prgmCLSCREEN
{146,222,255,0
Asm(prgmPRINT
0
Asm(prgmPRINT
While B<190 and Z≠45 and (O≠C or (B+20<R or B-10>R
While B<190 and O≤300 and (O≠C or (B+20<R or B-10>R
{5,F,G,5,D,I,3,12A,96,3,12A+80,96,3,12A+160,96,3,12A+240,96,4,C,B,M,O,R
Asm(prgmSPRITE
C→D
B→I
O→F
R→G
A+1→A
If A>13:1→A
getKey→Z
If Z=21:⁻40→E
E+10+10(E=⁻10→E
C-24(Z=24)+24(Z=26→C
If C<0:0→C
If C>288:288→C
If E>30:30→E
B+E→B
If B<0:0→B
O+24→O
R+20(M=2)((R<B)-(R>B→R
If Z=45:200→B
End
If (B+20≥R and B-10≤R) and O=C and not(M:Then
P+10→P:300→O
End
If O>288:Then
0→O
P+1→P
{146,222
Asm(prgmPRINT
P
Asm(prgmPRINT
20randInt(0,9→R
not(randInt(0,3))+(150<randInt(P,200→M
End
End
If Z≠45:Then
If B>188:188→B
0→θ
For(Z,1,10
not(θ→θ
{0,0,320,220,224+3θ
Asm(prgmCLSCREEN
{13+5θ,12A,96,13+5θ,12A+80,96,13+5θ,12A+160,96,13+5θ,12A+240,96,14+5θ,C,B,10+M+5θ,O,R
Asm(prgmSPRITE
End
{C,B,32,32,224
Asm(prgmCLSCREEN
{126,40,0,224
Asm(prgmPRINT
"Game Over
Asm(prgmPRINT
If P>ʟWALRS(1:Then
{112,60
Asm(prgmPRINT
"NEW HIGHSCORE
Asm(prgmPRINT
P→ʟWALRS(1
End
0getKey
Repeat getKey
End
Else
Asm(prgmBACKHOME
ClrHome
DelVar L₁Return
End
End


Also I need to update my game in Ticalc.org, Cemetech and TI-Planet download sections, because I noticed one of my copyright text turned into a token.

Hey, good news !!  :D

While reading my sources, I 've found some pieces of codes still optimisable : Sprites might be faster again ;)

That's cool. Also I need to take a look at how text linebreaks work, because I haven't checked the readme yet for the new command additions. Will v3.4 change to a different linebreak character that is easily reachable on the American TI-84+CE (such as the imaginary i)?

I'm studying the sources and keep careful : I wanna be sure that future optimisations will be safe ;)

Yes, concerning "linebreaks",  I chose the character i , which can be easily accessible on both TI83PCE & TI84+CE ,  and that's already available in version 3.3 ;)

Make sure the calculator won't detonate O.O

Kidding aside, good luck, and glad to see it's already available. I'll check if I can adapt my programs for it. :)


Also @grosged there is a problem with the French readme:

QuoteSi vous précédez SETTINGS du signe plus entre guillemet "+", cela forcera le programme
à rester en 16bpp (utile pour le débogage d'une erreur Basic!).

Special characters such as accents don't show up properly. Is it due to you using the wrong charset or is it due to me being on a North American machine?

I don't know, I just know my computer's OS is Linux (Ubuntu-based LinuxMint : https://www.linuxmint.com/ )
Maybe that's the reason why there are incompatibilities  ???

EDIT: I've just updated Instructions-FR.txt (no more french characters)

Maybe. It's strange, though. THat said at least there is the English readme :P

Linux computers usually use modern UTF-8, for maximum interoperability. é instead of é is a sign the file was opened with a text editor which doesn't support Unicode, or didn't automatically detect that the file contains UTF-8 characters :)

Yeah I normally use Notepad, but for most readmes I use Wordpad. I never saw much need to install a third-party text viewer just to open readme files, especially that most readme files I read are in English. :P