I see.
Still, try not to focus so much on making the game "exact," just do what you would do if you were making your own RPG.
Undertale Intro
Root / Submissions / [.]
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
Undertale is upscaled from 320x240 to 640x480 (2x upscale)
I dunno, I think that if they do have the willpower and time to make it as close as possible to the original product, and they have what they need to do it, I don't see any problem with doing it!
Yeah pretty much. 320x240 is upscaled by 2x to get the exact size, but with 400x240 you would have to upscale the x and not the y in order to fit perfectly, and that doesn't exactly look good.
or put a couple elongated pixels on the sides as borders, and i don't think people like borders that much
I don't really like them, I like to fill them with the map (like make the map the correct size o fit it) or with some sort of UI, like how super metroid has the missiles and other UI at the top of the screen
Hey, LeminWedj! I just realized a slight problem with using the bottom screen for basically the whole game. At the beginning of the game, you have to choose your name, and unless you want to go through the long, tedious, and hard process of coding that system, then you'd need the normal keyboard. And switching it to the top screen for only that one moment is really inconsistent, so what's ya plan?
Sorry
Edit: yes I know it can be inconsistent, but I usually have a problem with that. Although it may just be a me thing.
Replying to:
thou_fatGAMER12
thou_fatGAMER12Hey, LeminWedj! I just realized a slight problem with using the bottom screen for basically the whole game. At the beginning of the game, you have to choose your name, and unless you want to go through the long, tedious, and hard process of coding that system, then you'd need the normal keyboard. And switching it to the top screen for only that one moment is really inconsistent, so what's ya plan?
Sorry
Edit: yes I know it can be inconsistent, but I usually have a problem with that. Although it may just be a me thing.
I don't have a problem with making a keyboard (I have no experience with it, so I want to learn) but LeminWedj might have a different opinion
Replying to:thou_fatGAMER12
thou_fatGAMER12Hey, LeminWedj! I just realized a slight problem with using the bottom screen for basically the whole game. At the beginning of the game, you have to choose your name, and unless you want to go through the long, tedious, and hard process of coding that system, then you'd need the normal keyboard. And switching it to the top screen for only that one moment is really inconsistent, so what's ya plan?
Sorry
Edit: yes I know it can be inconsistent, but I usually have a problem with that. Although it may just be a me thing.
Writing a keyboard isn't too hard either. You can just create sprites of each letter (use the already existing font from the demo) and check for collision with a touch-controlled sprite.
Replying to:thou_fatGAMER12
thou_fatGAMER12Hey, LeminWedj! I just realized a slight problem with using the bottom screen for basically the whole game. At the beginning of the game, you have to choose your name, and unless you want to go through the long, tedious, and hard process of coding that system, then you'd need the normal keyboard. And switching it to the top screen for only that one moment is really inconsistent, so what's ya plan?
Sorry
Edit: yes I know it can be inconsistent, but I usually have a problem with that. Although it may just be a me thing.
Oh,okay. I never knew it was that simple. I thunkith it was a different system. O.K.
Replying to:thou_fatGAMER12
thou_fatGAMER12Hey, LeminWedj! I just realized a slight problem with using the bottom screen for basically the whole game. At the beginning of the game, you have to choose your name, and unless you want to go through the long, tedious, and hard process of coding that system, then you'd need the normal keyboard. And switching it to the top screen for only that one moment is really inconsistent, so what's ya plan?
Sorry
Edit: yes I know it can be inconsistent, but I usually have a problem with that. Although it may just be a me thing.
Or you could test collision based off of coordinates and make the keyboard entirely on the graphic screen, if you want to save sprites. That's what I'm trying out.
Replying to:thou_fatGAMER12
thou_fatGAMER12Hey, LeminWedj! I just realized a slight problem with using the bottom screen for basically the whole game. At the beginning of the game, you have to choose your name, and unless you want to go through the long, tedious, and hard process of coding that system, then you'd need the normal keyboard. And switching it to the top screen for only that one moment is really inconsistent, so what's ya plan?
Sorry
Edit: yes I know it can be inconsistent, but I usually have a problem with that. Although it may just be a me thing.
undertale requires a keyboard once, and that’s during the fight with mettaton. i’ll just use something like $response=INPUT “Response?” for it.
i was going to do some array math trickery getting the player’s name since that doesn’t need a keyboard. i can easily convert the numbers from the sprites to a $pName string.
Replying to:
MZ952
MZ952Oh, sweet, glad you found a use for my algorithm. Out of curiosity, how much did it shave off your project? The art and images in it look like they'd compress fairly well. No color gradients, large regions of similar color, etc.
i think for the image i used it on, it took off about 4/5 of the file size. and i actually used your algorithm since these specific images would be practically perfect use for it. the one thing about it though is that it takes noticeable time to decompress, so later i should make a separate program to decompress all arrays to image files before everything else runs instead of doing it when the file is needed.
Replying to:MZ952
MZ952Oh, sweet, glad you found a use for my algorithm. Out of curiosity, how much did it shave off your project? The art and images in it look like they'd compress fairly well. No color gradients, large regions of similar color, etc.
What I like to do is decompress the image on one gpage (or the same gpage just offset from view) and GCOPY it to where on the graphics page it should show.
This creates the illusion of instant draw time, but, if you're flicking through multiple frames, there'll be some maximum framerate at which you can draw new frames based on their complexity.
Replying to:MZ952
MZ952Oh, sweet, glad you found a use for my algorithm. Out of curiosity, how much did it shave off your project? The art and images in it look like they'd compress fairly well. No color gradients, large regions of similar color, etc.
when i say "is needed" i meant when the page gets initially drawn on a separate screen from its array. load times suck, so later on it would be better to decompress all the arrays to grp files as a first time setup, since its faster to load a grp than draw an array of boxes.
Replying to:MZ952
MZ952Oh, sweet, glad you found a use for my algorithm. Out of curiosity, how much did it shave off your project? The art and images in it look like they'd compress fairly well. No color gradients, large regions of similar color, etc.
Oh yeah, it is definitely faster lol
There are many other ways to compress image data, most far better than this method and for a wider range of image types. Actually I'm thinking about creating something like LWZ compression for just the sole purpose of making image files small
I guess when I built this, my only real concerns were keeping array sizes small and keeping drawing times "fast." An array of basically rectangle drawing instructions seems to be the compromise between these two constraints, because graphics operations on SB are pretty damn fast. Drawing times are short enough to do basic frame-by-frame animation (which is what this was actually built for).
LWZ compression could create really small files, but loading times would be at least an order of magnitude greater for a given image size. That would probably suit programs like yours better, if you're not attempting to do either whole-screen animations or displaying more images than raw data on free memory could handle.
Dude this is amazing. Would be pretty crazy to have a full game on 3DS
is the project still active?
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 doesn't seem likely.