SmileBASIC 4 Discussion「プチコン4」

That's really cool. Now I want to make a system like that lol.

Yeah, it was my intention to release the uh "finished" game along with like its component engines (the engine that handled drawing the tiles and their animations, as well as drawing entities overlapping with tiles, like water tiles and uh smoke and whatnot; and the engine that handled physics). By overlapping, I mean like, the engine could overlap text uh "textures" of like entities and tiles.

Spoiler

I guess the best image of this I have is from the dev phase of the game. Oh well, the water texture I created later on was much better. Actually...

Spoiler

https://youtu.be/l8Df4ABw5bQ

Unfortunately I never backed up the code so it's lost to me.

I think so. Isn't ATTR still a thing? Also, I recall reading something in the manual about being able to retrieve ATTR data, so yeah, I'm inclined to believe it's possible.

Hmm. iirc, I'm pretty sure ATTR affects the whole screen in SB3, but I could be wrong. I'll go figure that out now. EDIT: Guess I'm wrong. ATTR only affects text printed after it's used.

From the reference list and imo (since I do not have SB4 yet nor have I used SB3), ATTR in SB4 is more about assigning the default attributes to affect any text input after it's set. But, if you're looking to assign specific tiles with different attributes, there's always TPUT. And if you have TARRAY accessed, you can manipulate the entries that way (but be sure to use TUPDATE to validate the changes you make). That said, there wouldn't happen to be special command characters one can have in a string to force these attributes, could there?

That said, there wouldn't happen to be special command characters one can have in a string to force these attributes, could there?

I don't think so. In my engine, I believe I stored chars as integers. The first 16 bits of the int represented the actual character code to print, while the four bits ahead of it contained rotation and inversion information. Strings are 16 bit by nature I think, so unless you allocate space and disallow certain chars, you can't store the extra data. To actually print the character with rotation info, think I just simply did

 ATTR CHR_INT AND 1048575
PRINT CHR$(CHR_INT AND 65535)

You can always use the text screen itself as the storage medium. I think there's a way to get ATTR info, so one could read the screen and perform adjustments to individual characters at will.

I have to wonder though, is there a reason for them to make tiles primarily use hex, and start at such a high value? I don't understand why they wouldn't just start at 0.

Text screens and BG layers are the same thing now. The dedicated "console" screen is just text screen 4, and the only thing special about it is that it's the default target of certain functions. So, you can display text as well as BG tiles on the same layer. The BG tiles are mapped into the Unicode Private Use Area, because there's no characters encoded there and that's where you put special nonstandard character codes.

To elaborate on this, because text and BG tiles are merged, the numbers you use for TPUT are text character numbers, the same numbers that are used in stuff like CHR$() and ASC(). You can see this if you try using 65, the character code for "A".

TPUT 0,5,5,65
TPUT 0,5,5,ASC("A") 'equivalent
TPUT 0,5,5,"A" 'also works, because TPUT will accept a string

An English version of the PDF Guide has been released! It gives a quick summary of navigating SB4 and some of the basic features.

Cool

Looking over more of the reference list, I'm extremely interested in sprite variables. With PTC and SB3 (to my knowledge), you were limited to 8-numbered variables, which were simple variables. With SB4, this is greatly expanded as you make "names" for each variable for better readability, and also are not limited by the type of variable. Can even have an array if you wish. It's like a self-contained structure.

It would be better if we actually had dicts or structs in the language, though. From what I've heard about performance tests sprite variables are O(n) access and it doesn't seem like they use a hashtable inside. But I've also heard sprite variables 0-7 are optimized somehow, so who knows.

Even with my horrifically unoptimisable methods, I can easily fling a couple of thousand sprites around on the screen per frame. Assign spritesheet position values,, screen position, scaling, recolour, alpha, rotate, splat it on the screen. Handles it no problem. Silky smooth. And that's completely unoptimisable. If I ever bothered to RTFM and learn how to do this "properly", I'm sure I'd hit a new milestone in my abilities. Don't worry about the sprites, everyone. The sprites are fine!! (In comparison, FUZE absolutely hates my methodology, and struggles once it hits about 250 sprites)

Even with my horrifically unoptimisable methods, I can easily fling a couple of thousand sprites around on the screen per frame. Assign spritesheet position values,, screen position, scaling, recolour, alpha, rotate, splat it on the screen. Handles it no problem. Silky smooth. And that's completely unoptimisable. If I ever bothered to RTFM and learn how to do this "properly", I'm sure I'd hit a new milestone in my abilities. Don't worry about the sprites, everyone. The sprites are fine!! (In comparison, FUZE absolutely hates my methodology, and struggles once it hits about 250 sprites)

We're specifically talking about the SPVAR per-sprite variable storage, which has some potential performance issues. Sprites themselves are GPU-accelerated using standard graphics techniques, so they're extremely fast.

Exactly. You guys ARE bothering to optimise, but with the speeds I'm managing, unoptimised, it's going to be blazingly fast once you're all whittling away at it. My current issue seems to be with drawing backgrounds and buffers and tile layers and such. I really need to focus on learning to do that stuff well.

Exactly. You guys ARE bothering to optimise, but with the speeds I'm managing, unoptimised, it's going to be blazingly fast once you're all whittling away at it. My current issue seems to be with drawing backgrounds and buffers and tile layers and such. I really need to focus on learning to do that stuff well.

Well are you using SPVAR at all? If you are using it extensively then I'd be interested to hear how you feel about it.

No, I haven't needed to. That's kinda the point I'm making here.

It would be better if we actually had dicts or structs in the language, though. From what I've heard about performance tests sprite variables are O(n) access and it doesn't seem like they use a hashtable inside. But I've also heard sprite variables 0-7 are optimized somehow, so who knows.

Structures are what I'm probably going to miss the most from FUZE, but in all honesty, those are probably the reason why my programs seem to crash the app in the first place (structures within structures). So each newly added variable to a sprite will be slower to access than the one before it? Hmm....

Exactly. You guys ARE bothering to optimise, but with the speeds I'm managing, unoptimised, it's going to be blazingly fast once you're all whittling away at it. My current issue seems to be with drawing backgrounds and buffers and tile layers and such. I really need to focus on learning to do that stuff well.

Well are you using SPVAR at all? If you are using it extensively then I'd be interested to hear how you feel about it.

Mostly every program I've created in SB4 has relied on CALL SPRITE and storing sprite data in vars. I haven't noticed slowdowns until hitting thousands of sprites, but I also don't have too many individual sprite variables, maybe 8 at most and usually 4 or 5 in use. Usually I've seen slowdown around 2000 sprites, depending on how well optimized/how intensive your code is.

So I was browsing programs last night and found Spooky Maze. I loaded it up and was completely blown away! It runs at 60 fps at full resolution! I never thought I'd see a raycaster run so well after all these years. I really didn't realize until now just how powerful SmileBASIC 4 is. Maybe now I'll finally take the time to learn how to use that engine and make a game with it.

So I was browsing programs last night and found Spooky Maze. I loaded it up and was completely blown away! It runs at 60 fps at full resolution! I never thought I'd see a raycaster run so well after all these years. I really didn't realize until now just how powerful SmileBASIC 4 is. Maybe now I'll finally take the time to learn how to use that engine and make a game with it.

Yeah, I like the enhancements I was able to make, especially regarding using layer transforms for the floor rendering.

Asked about a setting to change the default UIRUN . At first it seems like they misunderstood the question but I eventually got "we're considering it" which could mean aaaanythiiing.

UIRUN?