See the many 10-page threads on this very topic.Espozo wrote:What's even the point of trying to make a compiler for the 65816? It's not bullshit complicated like modern x86 processors where you have instructions with 13 letter opcodes. The SNES is a pain in the ass to program for, but the problem is not the chip itself, but everything around it, (stupid memory mapping, weird hardware) and I don't see how C can solve this. Well, a good reason would be that far more programmers know C than 65XX assembly, but it's not incredibly difficult to learn.
Superfeather Game Engine v0.5.2b "Flying Kobold"
Moderator: Moderators
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
Congrats on the progress, your engine looks awesome. For now, i'm toying with C, but I hope someday to be able to code in ASM to use your engine in a game project
(I'm used to rely on BGB for GBdev, but I haven't found a SNES emulator with a similar feature)
Please excuse the newbie question, but how can you track CPU usage for SNESdev? Is there an emulator/debugger able to do that?HihiDanni wrote:However, CPU usage for when the metasprites are completely outside the screen is dramatically reduced: In the most extreme case it results in a decrease from 100% CPU to 25% CPU overall. For a bunch of objects trying to draw 512 hardware sprites total, I'd say this is pretty good.
(I'm used to rely on BGB for GBdev, but I haven't found a SNES emulator with a similar feature)
Download ROMs of my games: https://drludos.itch.io/
Support my work and get access to beta and prototypes: https://www.patreon.com/drludos
Support my work and get access to beta and prototypes: https://www.patreon.com/drludos
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
You can latch the HV counter just before you wait for vertical blanking and display how many scanlines are free. This works even on hardware.drludos wrote:Please excuse the newbie question, but how can you track CPU usage for SNESdev? Is there an emulator/debugger able to do that?
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
Correct, I latch the H/V counter to get whatever the current scanline is when I'm done processing the frame before VBlank. However, I also use a lookup table to translate that into a human-friendly value. You can find that lookup table here.
VBlank happens when the vertical counter is at V=225. However, the counter actually ranges from 0 to 261 (262 if using interlace). And depending on the length of your VBlank routine, you might finish your VBlank processing before scanline 0, so after V=225 you need to wrap your CPU utilization value back to 0. This lookup table takes care of that for you.
Also keep in mind that if you have slowdown (i.e. VBlank fires before you're finished with the frame), the CPU usage value won't be 100%, but will show you how much CPU you're going over by (assuming you only miss VBlank once, anyway). For this demo however, I check if there's been slowdown and cap the CPU meter at 100%.
P.S. I would appreciate it if this topic wasn't used to start language wars.
VBlank happens when the vertical counter is at V=225. However, the counter actually ranges from 0 to 261 (262 if using interlace). And depending on the length of your VBlank routine, you might finish your VBlank processing before scanline 0, so after V=225 you need to wrap your CPU utilization value back to 0. This lookup table takes care of that for you.
Also keep in mind that if you have slowdown (i.e. VBlank fires before you're finished with the frame), the CPU usage value won't be 100%, but will show you how much CPU you're going over by (assuming you only miss VBlank once, anyway). For this demo however, I check if there's been slowdown and cap the CPU meter at 100%.
P.S. I would appreciate it if this topic wasn't used to start language wars.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
Thanks a lot for the tip!
Counting the "idle lines" to estimate CPU load is very clever - I wouldn't have thought of that myself!
Is that how people did it in the 90's too?
@HihiDanni, I'll try to use your LUT to count the CPU usage with my C code.
Counting the "idle lines" to estimate CPU load is very clever - I wouldn't have thought of that myself!
Is that how people did it in the 90's too?
@HihiDanni, I'll try to use your LUT to count the CPU usage with my C code.
Download ROMs of my games: https://drludos.itch.io/
Support my work and get access to beta and prototypes: https://www.patreon.com/drludos
Support my work and get access to beta and prototypes: https://www.patreon.com/drludos
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
That and playing with the border color, color math, or other PPU features to get a visual sense of where the beam is when the code finishes. Even the NES has limited color math.drludos wrote:Counting the "idle lines" to estimate CPU load is very clever - I wouldn't have thought of that myself!
Is that how people did it in the 90's too?
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
I think an issue is not very many people know how to make a compiler.calima wrote:See the many 10-page threads on this very topic.Espozo wrote:What's even the point of trying to make a compiler for the 65816? It's not bullshit complicated like modern x86 processors where you have instructions with 13 letter opcodes. The SNES is a pain in the ass to program for, but the problem is not the chip itself, but everything around it, (stupid memory mapping, weird hardware) and I don't see how C can solve this. Well, a good reason would be that far more programmers know C than 65XX assembly, but it's not incredibly difficult to learn.
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
Correct. Even those of us who have attended college may not have taken compiler design as an elective. The only required language implementation course at my alma mater was "Programming Language Concepts", which spent 10 weeks on two things: 1. learning functional programming paradigm and 2. writing a Scheme interpreter in Scheme. Any less skilled or less experienced programmer can learn to write an interpreter.
So I guess it's a good idea to include enough basic functionality in this engine that programmers using it won't miss not having a compiler.
EDIT: Toned down the language
So I guess it's a good idea to include enough basic functionality in this engine that programmers using it won't miss not having a compiler.
EDIT: Toned down the language
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
True, not everyone is an expert on how to write a compiler, but there is still some groundwork already - the cc65 compiler. Obviously it doesn't support the 65816. It'd need to be adapted to the new instruction set, registers, and programming model, but at the very least it serves as a rough guideline.tepples wrote:Correct. Even those of us who have attended college may not have taken compiler design as an elective.
I suspect that a lot of the motivation behind the cc65 project is the large platform support offered by targeting the 6502 architecture. The 65816 unfortunately has seen a lot less use in computers, so it's not surprising that there isn't a ton of interest there. Should SNES homebrew kick off however, it might attract someone willing to take on the project of adding the missing 65816 support. Not saying it will happen, but it'd be cool, and I think worth striving for.
Is this the goal of the engine? Well, kind of... This is a game engine, a library, an abstraction layer. It's quite a bit different from a programming language, and not directly comparable. Writing your code in C won't save you from needing to write or use a game engine in some capacity. Nobody wants to fiddle with raw OAM manually every time they want an object to move across the screen (especially with the high OAM table). That's what abstraction layers are for. It's true however that a good library can make an otherwise not so great programming language more enjoyable to use (Qt and C++ for example). So yes and no. This engine is in assembly, but mostly because I want a solid foundation. Maybe someone could write some C bindings on top of it, or something similar. I think that'd be pretty neat. In any case, I like to think of this in more broader terms, i.e. making SNES programming easier, not just for assembly specifically.So I guess it's a good idea to include enough basic functionality in this engine that programmers using it won't miss not having a compiler.
Was this necessary?* A "moron" is a person with mild intellectual disability, the equivalent of elementary school aptitude.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
Does cc65 only run in 8-bit mode?
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
From the documentation for the cc65 compiler:
If you browse the source code there's a lot of assumptions made about the register set, so it would need some work to adapt it for the 65816. Still though...--cpu CPU
Set the CPU, the compiler generates code for. You may specify "6502" or "65C02" as the CPU.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
@HihiDanni, the NESmaker kickstarter was pretty successful. It had about 2,000 backers and $200,000+ raised. I think it would be great if you made a SNESmaker Kickstarter for your SNES game engine. What if it blew up and become really successful? Obviously people are interested in this kind of thing.
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
But you'd still need a compelling original Product Identity (that's IP spelled backwards) with which to test the engine, the way Mystic Searches was for NESmaker.
Re: Superfeather Game Engine v0.5.2b "Flying Kobold"
More generally, I intend this to be a project, not a Product. Identity I'm fine with (I had fun coming up with all the goofy codenames for each version), but ultimately I'm making this because it's something I decided to work on in my free time.
A fully-fledged "SNESMaker" would be scope creep for this project. I simply don't have the time and energy for something like that, not to mention running a campaign and the whole nine yards. Once you have expectations for deliverables (especially ones you are financially and/or legally responsible for), it kind of stops being a hobby.
A fully-fledged "SNESMaker" would be scope creep for this project. I simply don't have the time and energy for something like that, not to mention running a campaign and the whole nine yards. Once you have expectations for deliverables (especially ones you are financially and/or legally responsible for), it kind of stops being a hobby.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627