I disagree. I'm waiting for the Wii U release as well.

I'm surprised people are still surprised by screenshots like these... Step 1. Resize the webpage to 400x240px. It looks OK because it was made with basic responsive design in mind. Step 2. Take screenshot. Step 3. Transfer to SmileBASIC through super fast dial-up. Step 4. Share on Miiverse. Step 5. ??? Step 6. Profit.

Do you want some help? I may not be an expert in the field of trigonometry, but I can attempt to give you some clues on what to do, if you want!

Also, you shouldn't attempt to translate the game without first consulting the original creator. Maybe he wants to do his own translation, after all. Also, if you don't really know Japanese or if you are going to use a translation application, I'd suggest not trying to translate the program. After all, this work is usually left to the pros for a reason.

You shouldn't publish anything with Mario assets, or any other kind of copyrighted assets for that matter. This is why the game originally used its own assets. However, people have been changing the original sprites with no consideration of this issue. This is okay, as long as it isn't published. Do NOT publish copyrighted assets, or you may get publishing-related penalties.

Don't reupload other people's programs without permission. It's pretty rude... Besides, the original keys probably still exist.

You can specify a custom width and height for a sprite with SPDEF. You'd specify the definition number, the starting coordinates (the top left corner) of the sprite on the graphics page and the width and height. Like this... SPDEF <DefNum>,<OriginX>,<OriginY>,<Width>,<Height>

Don't lose hope! It is coming someday. I know it!

Con lo que no puedo concordar es en usar espacios en vez de un cólon, ya que el cólon es la estructura estandar para separar instrucciones que esten en una sola línea. Usar espacios puede causar errores inesperados y puede causar que el código se vea más confuso que ordenado. Aún no he visto el último programa que mandastes. Cuando pueda conectarme a internet desde el 3DS voy a poder ayudar.

Lo que sugiere raimondz es un poco más avanzado, pero permite una detección de colisión más facil, pero tambien más estricta. Te recomiendo que lo pruebes y determines si es mejor para ti.

I'm glad to see other people helping out! Keep up the good work!

Como queremos revisar si el usuario ha ganado constantemente, colocaríamos este código dentro del ciclo. En que parte del ciclo no importa demasiado, pero es recomendado que sea al terminar de actualizar los elementos gráficos. (En este caso, despues del SPOFS.) Si tienes alguna duda, o si no entendistes alguna parte de lo que dije, no dudes en preguntar.

Todo lo que vaya después de un REM es un comentario. Sería algo así... IF Y<=25 THEN REM Comparamos la posición vertical del carro (Y) con la de la bandera (25). Revisamos si es menor o igual ya que en la pantalla, la posición vertical va de 0 a 239 desde el tope hasta abajo. ?"FELICIDADES" BEEP 90 REM Le avisamos al usuario que ganó. ENDIF REM Nos salimos de la validación.

Ahora, para lo que me preguntastes. Puedes hacer una validación extremadamente simple en este caso. Solo tienes que comparar el valor actual de X (aunque, como mencioné, lo cambié a Y) y la posición vertical de la bandera. Como la posición de la bandera es una constante (un número que nunca cambia) podemos compararlo directamente. Lo que vaya dentro del IF sería lo que quieras que pase.

También cambiaría el VSYNC 2 a un VSYNC 1, para que el programa corra a 60FPS. También movería el SPOFS de la bandera antes del ciclo, ya que solo ocupas moverlo una vez. Además, cambiaría el SPOFS a 200,25 para que este más centrado con respecto al carro. También puedes cambiar el X=X-3 a DEC X,3. Similarmente el X=X+3 a INC X,3. Esto es por legibilidad. Estas serian todas las recomendaciones.

Reemplaza el ciclo que tienes con GOTO con un WHILE...WEND. Es muy recomendado usar estructuras definidas en vez de usar GOTOs. Para hacer esto solo reemplaza el @P con WHILE TRUE y el GOTO @P con WEND. Tabula todo lo que esta dentro del ciclo. Es decir, pon un espacio antes de cada linea del código dentro del ciclo. Esto mejora la legibilidad del código.

Aqui tengo algunas recomendaciones para tu código... Pon los SPSETs afuera del ciclo. Solo ocupan correrse una vez, entonces puedes ponerlos antes del ciclo. Cambia el nombre de la variable de X a Y. Esto es por la naturaleza de la variable, ya que se usa para definir la posición vertical del carro. Es una buena práctica de programación usar nombres descriptivos para las variables.

With this information you can easily offset something's position by incrementing its coordinates using STICK's values, like this... 'X AND Y = COORDINATES OF SMTH TO MOVE STICK OUT SX,SY INC X,SX*2 'MULTIPLY TO "CHANGE MOVE SPEED" DEC Y,SY*2 'DEC Y SINCE SY IS NEGATIVE RELATIVE TO GRAPHIC SCREEN 2. I can't really give you much help with this one right now, sorry. Use BGOFS, maybe?

I suggest running this simple program to observe the instruction's behavior... WHILE TRUE STICK OUT SX,SY ?"SX:";SX:?"SY:";SY GCIRCLE 200,120,50 GCIRCLE 200+SX*50,120-SY*50,5,#RED WAIT 1 CLS:GCLS WEND Also, if you have a New 3DS or a Circle Pad Pro you can also use STICKEX in the exact same way to receive stick information from the C-Stick.

1. Use the STICK instruction. It follows this syntax... STICK OUT SX,SY ...where SX and SY are values that range between -1 and 1, which represent the stick's position relative to it's default position. (Note that the actual values will be closer to ±0.86) This values are updated as soon as you call STICK OUT again, so it is recommended to call it within a loop.