|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
![]() |
Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next |
Author | Message |
---|---|
|
![]() |
Yes, the fact that the SMS VDP does not allow changing vertical scrolling mid frame can be a bummer, sometimes. |
|
![]() ![]() ![]() |
|
|
![]() |
Haroldo look to this game from 7800: It seems to use the same technique from Rad Racer with segmented road. Would be possible our SMS have a similar game? Poderia o nosso Master rodar um jogo de corrida similar? |
|
![]() ![]() |
|
|
![]() |
Most horizon-chasing games on the Master System use per-line scrolling for making the horizontal bends. Making hills is trickier, since its VDP does not allow changing the vertical scrolling midframe. | |
![]() ![]() ![]() |
|
|
![]() |
MSX tile editor + tutorial:
At least it could help in create coleco/SG-1000 sprites. Download here: https://www.electricadventures.net/Pages/Category/24 |
|
![]() ![]() |
|
|
![]() |
Sprig's built-in editor does give me a few ideas...
https://sprig.hackclub.com/gallery |
|
![]() ![]() ![]() |
|
|
![]() |
Here, I'm trying to teach "ChatGPT" to generate code for some random programming language, in this case, "choice4genesis"; normally, it you tried to do it in english, it will return a "Sorry, Dave" canned answer, but if you teach it in Portuguese first, then ask the questions in english, it works okay.
|
|
![]() ![]() ![]() |
|
|
![]() |
This interesting project uses an infrared camera to emulate various light guns:
https://github.com/radioation/Devastar |
|
![]() ![]() ![]() |
|
|
![]() |
Interesting turn based strategy for the SMS:
|
|
![]() ![]() ![]() |
|
|
PCE 3375 color mode
![]() |
PC-Engine "3375" color mode slide show
|
|
![]() ![]() |
|
|
![]() |
Interesting; I didn't know Borgman was actually a Zillion spinnof:
|
|
![]() ![]() ![]() |
|
|
![]() |
I like in put NES development videos here because is a system next to SMS with some concept that could be useful for dev here.
First a golf game with explanations about calculations used: Now a amazing demo achieved in NES: and other: |
|
![]() ![]() |
|
|
![]() |
A very, very polished c64 homebrew that could inspire SMS coders:
A Pig Quest for C64 (what tags do I use to embed a YT video?) |
|
![]() ![]() |
|
|
![]() |
Stumbling aroung Github, I found this promising project by bolon667, SGDK Platformer Studio.
|
|
![]() ![]() ![]() |
|
|
![]() |
Interesting 3D effect on the NES:
Seems to just be using the good old pallete change per scanline when walking, some limited tilemap animation when turning around, plus sprites for the spheres. Still, the overall result is better than one would expect. |
|
![]() ![]() ![]() |
|
|
![]() |
The NES is obnoxious and makes it really difficult to change palettes in the middle of the screen, so I believe that's not what's happening in that video. Instead, that's almost certainly just X scroll changes.
The game "The 3-D Adventures of World Runner" uses almost the exact same effect. |
|
![]() ![]() |
|
|
UgBASIC
![]() |
https://ugbasic.iwashere.eu/
ugBASIC seems to support SG1000 |
|
![]() ![]() ![]() |
|
|
![]() |
Confirmed: https://ugbasic.iwashere.eu/targets |
|
![]() ![]() |
|
|
![]() |
Pretty interesting tunnel effect by kakalakola:
Source on github: https://github.com/kakalakola/RetroDev/tree/master/SEGA/Master%20System/Tunnel%2... So far, I have only taken a cursory look at the source; it seems to be updating 11 palette colors every 2 lines; it seems to be a similar trick to the one used on Mickey Mania for the Sega Genesis: |
|
![]() ![]() ![]() |
|
|
x86 to Z80 assembly translation
![]() |
https://github.com/janwilmans/x86-to-z80
It seems far from useful yet but it's a great idea. |
|
![]() ![]() ![]() |
|
|
![]() |
https://www.youtube.com/watch?v=iZF4sickrI4&ab_channel=Geppo%27sMSXAdventure
Nice MSX Turrican WIP. |
|
![]() ![]() ![]() |
|
|
![]() |
This demo was developed by Trirosmos and team. Was in plans of authors a SMS version. Too bad dont have it complet.
|
|
![]() ![]() |
|
|
![]() |
Interesting documentary about old Amiga diskmags:
|
|
![]() ![]() ![]() |
|
|
![]() |
Well ...
I dont know how much inspiring It can be, but I wanted to share with everyone here the video of a game which Will be available here in smspower soon, in its dedicated thread. Regards https://m.youtube.com/watch?v=e6-dERyF-oA&feature=share |
|
![]() ![]() |
|
|
![]() |
What! Journey to Silius for Master System? Fantastic graphics, awesome music, superb story, marvelous framerate. A true electronic dream. |
|
![]() ![]() |
|
|
![]() |
This can help sms new developers?
I hope so https://github.com/NesHacker/PlatformerMovement |
|
![]() ![]() |
|
|
![]() |
Nice video, I like this guy's stuff. | |
![]() ![]() ![]() |
|
|
![]() |
Interesting demake of Super Star Soldier for the Sega Mark III:
|
|
![]() ![]() ![]() |
|
|
![]() |
I wouldn't call it a demake. It's actually a surprisingly accurate recreation of SSS's caravan mode. I love how he changed a few things subtly to get around the 8 sprites per line limit, like reworking the ring enemy or changing the score items from 16 x 16 spheres to 8 x 16 diamonds.
If I'm not mistaken, this is from the same guy who coded GG Aleste 3, so he clearly knows what he's doing. |
|
![]() ![]() |
|
|
![]() |
There is a parallax effect with a shadow cast on top of it. | |
![]() ![]() |
|
|
![]() |
Perfectly feasible with animated backgrounds; it just requires more tiles. |
|
![]() ![]() ![]() |
|
|
![]() |
Interesting explanation on how Yoshi's Island does its graphics:
|
|
![]() ![]() ![]() |
|
|
![]() |
“It doesn’t have to make sense. Don’t think! Just feel! Embrace the mystery!” Very inspirational advice. |
|
![]() ![]() ![]() |
|
|
![]() |
Interesting 3D effect on the MSX:
|
|
![]() ![]() ![]() |
|
|
![]() |
Unfortunately it turns out that demo video was recorded on an emulator running at MSX TurboR CPU speeds... so even though Xelden Ring can run on just MSX1 spec, the frames are rather slow | |
![]() ![]() |
|
|
![]() |
I see... thanks for the info |
|
![]() ![]() ![]() |
|
|
![]() |
Interesting visual explanation of a few simple maze generating algorithms:
|
|
![]() ![]() ![]() |
|
|
![]() |
This interesting tool allows one to make Apple II games using a Bitsy-like editor:
https://spindleyq.itch.io/8-bitsy |
|
![]() ![]() ![]() |
|
|
Sega Neptune builds in 2023
![]() |
People are building their own Sega Neptune based on photos in print media the time. People are awesome.
https://www.youtube.com/watch?v=oz_8-sqxLjs |
|
![]() ![]() |
|
|
![]() |
Complex code and bomb colisions fixed. |
|
![]() ![]() |
|
|
![]() |
This AI can generate a simple game from a single image:
|
|
![]() ![]() ![]() |
|
|
![]() |
Multiplexed sprites on Genesis.
|
|
![]() ![]() |
|
|
![]() |
Other video that explore techniques for minimal use of memory
|
|
![]() ![]() |
|
|
![]() |
This could happen to SMS too?
Or the method in Sega 8bit is more elegant? |
|
![]() ![]() |
|
|
![]() |
Hard to say. I watched the video a few days ago, so don't remember exactly about the crash, but I imagine it would be similar, since it involves a jump from an address stored in RAM. But for the glitched colours, I think it's less likely that that problem would happen on the SMS. IIRC, the problem was that they used a BMI (branch if minus) instead of BCC (branch if carry clear....it works backwards on a 6502 when subtracting/comparing). BCC would only take the branch if the subtraction caused it to roll below 0. But BMI could cause it to branch because the number was too high after the subtraction. Since those instructions on the 6502 take up the same number of cycles and bytes, it's probably a matter of preference if you can guarantee that the number won't be too high. They thought they could, but never anticipated anyone getting past level 29. |
|
![]() ![]() |
|
|
![]() |
Well, considering that Z80 is a different processor i was thinking that no way in happen the same bug but you have better knowledge about both systems so... |
|
![]() ![]() |
|
|
![]() |
Well, maybe about the 6502! Don't sell yourself short on your prowess over the Z80 and the Master System! But yeah, the colours glitch boils down to the fact that there is no penalty for branching based on sign flags vs carry flags on the 6502. On the Z80, it's more likely the carry flag is used since it works for relative jumps. For the crash part, I think it had to do with a jump with a direct, not immediate, address. On the Z80, this would be a JP (HL), and would require an extra step of loading HL with whatever. On the 6502, it can simply jump to an address stored in memory. You give it the address of the low byte, and it uses the next byte as the high byte, and goes there. If the bytes on a game console are in RAM, and you hit unpredicted levels, the offsets go beyond what the developers predicted, and the jump goes to execute bytes not meant to be code, and it breaks the game. Really, it's a different cause, but not much different a result from what happens if you mess up the stack in a subroutine. If you have a branching jump routine based on a task number in RAM, and somehow an unpredicted value that's longer than your task list goes into RAM, you're usually in trouble. |
|
![]() ![]() |
|
|
![]() |
The crash bug is just an interrupt handler that mutates memory (specifically two zero page entries) being used elsewhere, so it's a general class of fault that pretty much any processor of the era would encounter. The 6502 is perhaps more susceptible because it only has three registers and so uses zero page RAM extensively for temporary storage. In the Z80 it's more likely that the CPU's registers would have been used, and it's conventional to push used registers to the stack inside an interrupt routine, which would have mitigated a problem like this.
I don't know the code for this game, but it seems likely to me that there would have been other zero page slots free for the NMI handler to use for working data, so I would guess that this bus was entirely avoidable! |
|
![]() ![]() ![]() |
|
|
![]() |
Yeah. I don't know the code terribly well either, but a few videos came out about it that described what causes the issues. The main problem simply boils down to the game designers assuming that level 29 was unbeatable, so $1d was the maximum assumed offset for anything that used the level number as an offset. I still maintain that it would have been less likely to occur on the Z80, just because the carry flag would be used instead of the sign flag, since you can't do a relative jump with the latter. I do agree, though, that the common practice of pushing registers onto the stack on the Z80 would help too. Didn't even think of that. |
|
![]() ![]() |
|
|
![]() |
Well, if I understand correctly, the crash doesn't really happen because of bugs but because the score calculation happens to eat too many CPU cycles later on.
In other words, even with all the bugs still present, if one replaces the current code that handles the score with something that performs in a (safe) fixed amount of time - which is totally possible - then the resulting ROM will be still bugged but won't crash. Am I wrong? :| |
|
![]() ![]() ![]() |
|
|
![]() |
Perhaps a philosophical question of "what is a bug?", but yeah I think you're right - it's the combination of the score calculation taking more than a frame and the fact that the ISR isn't safe that create an issue here. If you were to fix either of those problems then I think the crash wouldn't happen. If you only fixed the ISR not being safe then the score would still presumably cause a slow down, either once as it ticked past 99999 or whatever, or every frame thereafter I'm not sure. If you only fixed the score calculation performance then I think everything would work fine, except I guess the score would still read a weird value. |
|
![]() ![]() ![]() |
![]() |
Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next |