Did some digging, it was using the xlibc commands from DCS8.2:

https://dcs.cemetech.net/SDK/CSE/BASIC/Libraries/

xLIBC/xLIBCE Libraries #

xLIBCSetup - real(0,FN,Value)
UserVariables - real(1,FN,Uservar_Num[,Value])
GetKey - real(2,FN[,Args])
DrawMap - real(3,FN[,Args])
DrawSprite - real(4,FN[,Args])
ManagePic - real(5,FN[,Args])
DrawString - real(6,FN[,Args])
DrawShape - real(7,FN[,Args])
xLIBCUtility - real(8,FN,Val)
UpdateLCD - real(9)\

I had forgotten I had dabbled in some xlib things, so those 2 mentioned programs will probably never work for the CE.

Working on trying to freshen up my knowledge on Celtic and how I may want to tackle some of my projects going forward. Thinking I want to play around with some sprites to move around a screen, since all the basics of BASIC are still pretty solidly in my mind

So I've spent the last little while working out story board ideas, some game mechanics, and the like.

I'm thinking my next step will be working out some form of map walking mechanic. As I'm using Celtic for this project, I'm debating on if I want to use 32x32 graphics, or swing down to 16x16, giving "more" on the screen at a lower resolution. Regardless of which size, only 160x256 of the screen would be used. Which we can center it a little and make it look a little cleaner.

Just kind of wondering thoughts on this, and appreciate any opinions on this part of the planning phase.

I think it would depend on the style of game. If it's more story-based, I'd say that 32x32 would be nice as higher-resolution graphics are always great. However, if it's more puzzle-based, seeing "more" on the screen makes a lot more sense to me and makes puzzle games more convenient, so for that I would lean to 16x16 tiles.

It's going to be an RPG, potentially with puzzles of some kind? I'm still putting down the finer details.

I was wanting the 32x32 for the better details of what the sprites can be, but the size of the sprites in terms of data will eat up a lot of space very quickly. Guess I just need to sit down and try to come up with some temporary versions in both sizes and see what I can do with it.

I also feel like I'm remembering an asm program for the monochrome calculators that would shift the screen in one of the 4 directions, but doesn't seem Celtic CE offers that. Going to have to work around that for the engine since I was thinking about using the Pokemon Purple walking engine, just overlayed with sprites.

By 160x256 do you mean 256x160? Because the screen height is 240 pixels not 256 . At 256x160 it would probably remind me of games like Legend of Heroes/Dragonslayer released in Japan.

Also Celtic CE does have screen shifting including the ability to shift only a portion of the screen. It would be det(58, direction, amount, x, y, width, height). It got added again later on in the Celtic CE project.

Hm, I looked over the docs but must have missed that, I'll have to go read up on them better. Thanks for letting me know!

Alright, little update.

I've been poking around with taking notes on the story board. I still need to work on a map of some kind, which will become quite important pretty soon, after I can create myself a walking system along with a spriting/mapping system.

Just wondering if anyone has any good sources for sprites, in the 16x16 range. I've found some, but they all seem to want money for them, even if they give sheets you can swipe with the snipping tool. I'm currently looking for a basic player character I can use to move around, and some basic ground/world based sprites.

A few resources I found:

• https://itch.io/game-assets/free, especially https://itch.io/game-assets/free/tag-16-bit
  
• https://opengameart.org/ (Browse -> 2D), including https://opengameart.org/content/sprites-2
  
• https://assetstore.unity.com/?price=0-0&q=16-bit%202d%20character&orderBy=1

Ooo thanks! I've been poking around and finding sites, but everyone wants money. I have no problem paying for them, but for now, I just want some not great sprites to play around with.

If it helps, I searched for "royalty free sprites", with variations of "8-bit" and "16-bit" in there as well. Helpfully, many royalty-free sprites are also free.

I know it's been a while. Work has been whooping on me, and I'm still trying to get my streaming thing going.

Anyways, finally getting some progress made on making sprites. I've created a cobble looking thing to play around with, wanting to get a couple of others to maybe have some variety in trying to display the map screen.

I promise, I really want to program, I'm not all talk. Just too many hobbies and too many things wanting my attention at once.

I finally made the attempt to display the cobble sprite (because I'm trying to break past all the exhaustion to still try to make this work) and I've managed to display.. Something. det(9 and det(10 doesn't require anything special set before using, does it? The sprite that displayed was garbled, and it was generated via Spriter. Might retry making the sprite and see what that does for me..

Hmm, interesting! I've tested Spriter myself with a BufSprite sprite on my own calculator and I'm not seeming to encounter the problem, though it still could possibly be a Spriter issue. Would you be able to post the string generated by Spriter?

In case it's not a Spriter issue, what arguments are you passing to BufSprite when you call it? You probably are already doing this, but are you 100% sure that Str9 does contain the sprite data when BufSprite is called?

ClrDraw:ClrHome
"08FF9595FF0808959508FF9595959508959595959508FF0808FF0895959595080895959508FF95959595FF089595080808080808FF9595959595FF0808080808FF08080895959595959508FF080808FF95FF08089595959595950895FF08FF95959508089595959595089595FF08959595950808959595950808080808089595"->Str9

det(9,16,20,50

Is my little test of a program. As I've not messed with a lot of sprite displaying things, I figured it would be smart to start small, make it display 1, then go through and display a bunch. Until I get the hang of things.

Hmm, definitely looks like it's an issue with the sprite that was generated. If you don't mind, could you try creating the sprite again and see if you have the same issue?

I'll try to find some time to redo it, hopefully this weekend.

There's probably no need to remake the sprite unless I intend to use the smaller color list.. It didn't click with me that what I was using was for xlibc, not for the bufsprit until I went to use Spriter again.. So the errors and issues were on my end, I apologize. I didn't realize you only had the primary calc colors with spritebuf, so I need to see what the xlibc commands and such are, I haven't played with it in a long, long, LONG time.