LoginLogin
Might make SBS readonly: thread

Undertale Intro

Root / Submissions / [.]

LeminWedjCreated:
Download:5KXNXXNX
Version:1.0.2Size:0.69MB (nice)
NOTICE: This project will likely never become a full game port due to the tileset in the original game being 20x20. I absolutely cannot be bothered to make a new library for handling bg tiles of any size. It took three hellish months and a summer away from working on this to complete, but I did it, I finally did it. It's (mostly) the Undertale intro you know and love, painfully remade in SmileBASIC 3 with as much accuracy as I was bothered to get, complete with custom MML music and a nearly complete textbox system that handles strings in a similar way to the original game. Thank you to MZ952 for the image compression algorithm. Link to the project page: https://smilebasicsource.com/page?pid=1535 A couple other things to note: - The way i'm playing the sound samples for text is most likely inferior to some other method of doing it, spare buying the DLC - I can feel that the way i made the text box system is disgusting. The main issue is that i've just allocated sprite 400 to 500 for text only, which chews into the sprite limit. - If I am able to continue with the rest of the game, there is no way this can be uploaded to the smileboom servers because of its size. They also might take it down like they did with a couple other things. - do not expect a consistent update schedule for this. every project i work on is in a "do whenever" state. also i threw in a bonus practice program that looks neat

Instructions:

A - Skip to end of text B - Advance text Y - unused for now Dpad - unused for now Hold START to exit any program easily.

Notes:

Hotfix 1.0.2

5/12/2020 - Added boxes around image slides to correct their size - Positioned intro text to correct height

Update 1.0.1

5/9/2020 - Implemented compression for GRP files - Removed currently unnecessary GRP file - probably added an extra screen
ProgramsGamesRole Playing Game
Tarudahat#1
It's awesome. Also if you are gonna remake the whole game you could share the game by turning every file U use for it into a .TXT and just past it all in a forum or something. So that someone could just copy the text into a .txt and then rename the .txt to whatever file type it needs to be (I don't know if it would work I just got this random idea ones)
LeminWedj#2
Replying to:Tarudahat
It's awesome. Also if you are gonna remake the whole game you could share the game by turning every file U use for it into a .TXT and just past it all in a forum or something. So that someone could just copy the text into a .txt and then rename the .txt to whatever file type it needs to be (I don't know if it would work I just got this random idea ones)
Yes, there’s ways to just export the entire project file as a .zip with some homebrew so that others can use it like that, but some people either don’t like the idea of homebrew or can’t wait days for multiple file transfers using petit modem. It would definitely be a more difficult project to acquire either way. Here’s the page for the homebrew method of file transfers. This was a godsend to me when I found it. https://smilebasicsource.com/page?pid=308
MZ952#3
I thought button input could be rendered at arbitrary times? At least 60 fps. Just uh count the milliseconds, and only selectively render inputs at 30 fps margins.
S_DE_Solutions#4
The Result looks fine. Hint for your Problems: You could use background images for the intro instead of sprites (to save sprites). I think 60fps would be possible. But the source code should have to be structured (differently). This would also be useful, so that the button inputs always work in real time. (Each line of code needs a certain time to execute. It's not much, but the more computations and jumps the main loop has, it get more visible. By the way: have a look to https://smilebasicsource.com/page?pid=1316 for information how vsync works in Main-Loop.
chicken#5
Replying to:S_DE_Solutions
The Result looks fine. Hint for your Problems: You could use background images for the intro instead of sprites (to save sprites). I think 60fps would be possible. But the source code should have to be structured (differently). This would also be useful, so that the button inputs always work in real time. (Each line of code needs a certain time to execute. It's not much, but the more computations and jumps the main loop has, it get more visible. By the way: have a look to https://smilebasicsource.com/page?pid=1316 for information how vsync works in Main-Loop.
He wants the game to run at 30fps, so it'll be a perfect recreation of Undertale.
hakke#6
You could do this: 
WHILE #YES
  BTN=BUTTON(1)
  INC TIMER
  IF TIMER MOD 2 THEN
    'DO YOUR 30FPS STUFF HERE
  ENDIF
WEND
IIRC, the inside of the IF block will run at 30fps, and the rest at 60.
LeminWedj#7
Replying to:S_DE_Solutions
The Result looks fine. Hint for your Problems: You could use background images for the intro instead of sprites (to save sprites). I think 60fps would be possible. But the source code should have to be structured (differently). This would also be useful, so that the button inputs always work in real time. (Each line of code needs a certain time to execute. It's not much, but the more computations and jumps the main loop has, it get more visible. By the way: have a look to https://smilebasicsource.com/page?pid=1316 for information how vsync works in Main-Loop.
The slides actually aren't sprites, they're being copied off of another graphic layer. The issue with them isn't anything with sprites though, its just how huge the slides are. If you peek into the GRP file for the slides you can even see that I actually had to wrap them around the screen instead of placing them in full, so some slides need two GCOPY commands. And i've also seen the gsync and wait battle royale. It's not exactly what i'm looking for, but it's a good way to understand what the difference is between the two commands. I'm thinking i might need another program slot dedicated to constantly polling input, but that's an absolute mystery to me as to how that would work.
LeminWedj#8
Replying to:hakke
You could do this: 
WHILE #YES
  BTN=BUTTON(1)
  INC TIMER
  IF TIMER MOD 2 THEN
    'DO YOUR 30FPS STUFF HERE
  ENDIF
WEND
IIRC, the inside of the IF block will run at 30fps, and the rest at 60.
That's viable, in fact i've already used that for the text function, but imagine doing that in every part of the program. There still needs to be a way of determining which input to use out of both "frames."
hakke#9
Replying to:hakke
You could do this: 
WHILE #YES
  BTN=BUTTON(1)
  INC TIMER
  IF TIMER MOD 2 THEN
    'DO YOUR 30FPS STUFF HERE
  ENDIF
WEND
IIRC, the inside of the IF block will run at 30fps, and the rest at 60.
Maybe 
BTN=BUTTON(1)
VSYNC
BTN=BTN OR BUTTON(1)
'DO STUFF
VSYNC
That will get the input from both frames as one single button. So if you perfectly press up in one frame and right in another you'll get up and right as a button.
LeminWedj#10
Replying to:hakke
You could do this: 
WHILE #YES
  BTN=BUTTON(1)
  INC TIMER
  IF TIMER MOD 2 THEN
    'DO YOUR 30FPS STUFF HERE
  ENDIF
WEND
IIRC, the inside of the IF block will run at 30fps, and the rest at 60.
You know what, i'll try that. I think i'm stuck on importance of button states too much.
Minxrod#11
You could get 60FPS input and store to a buffer array/vars of 2 inputs, that way you can read both inputs in one frame or select one to use.
rando#12
It's a nice start
12Me21#13
It's fine to just check BUTTON on every other frame. It's nearly impossible to press a button for just a single frame, so you'll never miss any presses. (I tried for a few minutes and was never able to do it. I think they might just be ignored by button debouncing. Either they ignore button presses less than 2 frames, or don't allow a button to change state on 2 frames in a row.) 
WHILE 1
 VSYNC
 OOB=OB
 OB=B
 B=BUTTON()
 IF !B && OB && !OOB THEN ?"1 Frame button press!"
WEND
12Me21#14
Replying to:12Me21
It's fine to just check BUTTON on every other frame. It's nearly impossible to press a button for just a single frame, so you'll never miss any presses. (I tried for a few minutes and was never able to do it. I think they might just be ignored by button debouncing. Either they ignore button presses less than 2 frames, or don't allow a button to change state on 2 frames in a row.) 
WHILE 1
 VSYNC
 OOB=OB
 OB=B
 B=BUTTON()
 IF !B && OB && !OOB THEN ?"1 Frame button press!"
WEND
But if I'm wrong, you could just do something like this: 
WHILE 1
 OLD_BTN=BTN
 VSYNC
 BTN=BUTTON()
 VSYNC
 BTN=BTN OR BUTTON()
 BTN2 = OLD_BTN AND NOT BTN
 etc.
 ...
WEND
HTV04#15
Please, please don't make the game 30FPS if you're going to try to make the entire game. I get that it's accurate to the original, but 60FPS would be SO much better and smoother. It would be a really nice improvement over the original. Also, quick note that the game probably would have been 60FPS if it weren't for GameMaker's limitations.
HTV04#16
Replying to:Tarudahat
It's awesome. Also if you are gonna remake the whole game you could share the game by turning every file U use for it into a .TXT and just past it all in a forum or something. So that someone could just copy the text into a .txt and then rename the .txt to whatever file type it needs to be (I don't know if it would work I just got this random idea ones)
Note that you can upload it to SmileBoom's servers temporarily and save it to your computer via SBAPI, then remove it from their servers and upload it somewhere else.
rando#17
Replying to:12Me21
It's fine to just check BUTTON on every other frame. It's nearly impossible to press a button for just a single frame, so you'll never miss any presses. (I tried for a few minutes and was never able to do it. I think they might just be ignored by button debouncing. Either they ignore button presses less than 2 frames, or don't allow a button to change state on 2 frames in a row.) 
WHILE 1
 VSYNC
 OOB=OB
 OB=B
 B=BUTTON()
 IF !B && OB && !OOB THEN ?"1 Frame button press!"
WEND
The problem with checking every other frame is when you're using IF BUTTON(2), but you don't have to use that.
rando#18
Maybe we could ask Toby Fox if he is fine with us cloneing Undertale. Then we could clone it, if we had the skills.
12Me21#19
Replying to:12Me21
It's fine to just check BUTTON on every other frame. It's nearly impossible to press a button for just a single frame, so you'll never miss any presses. (I tried for a few minutes and was never able to do it. I think they might just be ignored by button debouncing. Either they ignore button presses less than 2 frames, or don't allow a button to change state on 2 frames in a row.) 
WHILE 1
 VSYNC
 OOB=OB
 OB=B
 B=BUTTON()
 IF !B && OB && !OOB THEN ?"1 Frame button press!"
WEND
oh, in that case you can just use something like 
WHILE 1
 VSYNC 2
 OLD_BTN=BTN
 BTN=BUTTON()
 BTN2=BTN AND NOT OLD_BTN
 ...
WEND
HTV04#20
Replying to:rando
Maybe we could ask Toby Fox if he is fine with us cloneing Undertale. Then we could clone it, if we had the skills.
I'm pretty sure he's fine with fangames. And... uh... the fandom.
1234