|
Post by Arkhan on Jan 12, 2020 15:50:13 GMT
Fair enough, it is tied to HuC, and I'll explain the reasons: 1) There was nobody back then (besides the authors of the compiler) who had any intention of writing in assembler. I participated in HuC thinking that it would be the gateway to bring "regular gaming programmers" (in the context of the 90s) to the point of becoming more comfortable with assembler.
I think this is kind of sad. HuC is quite capable of producing great games, with little to no assembly. I'm 100% reliant on HuC to make my games, and I'd like to think they are competent, quality games, despite the lack of asm knowledge.
its a sad truth that you really need to use assembly to get anywhere with game making on old machines for the most part. Genesis and such are more C friendly. 6502 is inherently not C friendly. Even with the stuff Elmer may have improved, I don't think I would be 100% confident that it juices up the speed enough in times when you'd really need it. I'm not sure how it does stuff like handling function parameters and stacky-stuff. That shit is inherently slow and the lack of registers on the PCE sucks, so you have to use the zero page, but then you get into "weird land" where if the compilers fucking around with the zero page, you probably can't do things you want to do in the zero page if you're inlining assembly, and then it all gets fuckin weird. ISOLink would maybe be OK if there was a way to generate pure data banks easily. AFAIK, there isn't a way that works. Maybe I missed it. I never saw it in the documentation outside of claiming you can do it. One way we found was that you make a program overlay that includes your data, and then you strip the program crap out and fudge it. That makes it clumsy to use for data loading, and not really intuitive or clear to people who arent sure what they're doing but need to load graphics into VRAM. also, semi relevant: loled @ Elmer's tone getting a poor reaction out of someone besides me for a change. 10/10
|
|
|
Post by dshadoff on Jan 12, 2020 18:11:42 GMT
For the record, I didn't really believe in the concept of HuC when David Michel came up with it - for pretty much the same reasons that you state. 'C' was basically made for 16-bit (and up) processors; it produces bad code on 8-bit processors, and promotes some bad habits on processors with limited registers.
David and Zeograd came up with a couple of interesting demos and persuaded me, explaining that it was a faster way to write some basic code, but that people would want to do better, and learn assembler for the critical portions... which made sense to me at the time. I enjoyed coming up with solutions to the tricky bits (system startup, CD usage), and considered them proof-of-concept code.
But mostly it's sat in its original state for years at a time, without particularly heavily usage, and it just feels a bit weird for something so under-utilized, for an architecture with so little information known to the public, to be criticized for its lack of development. Like mocking Francis Crick for discovering the helical structure of DNA back in the 50's, but not having sequenced it at the time.
|
|
|
Post by DarkKobold on Jan 12, 2020 18:12:58 GMT
I think this is kind of sad. HuC is quite capable of producing great games, with little to no assembly. I'm 100% reliant on HuC to make my games, and I'd like to think they are competent, quality games, despite the lack of asm knowledge.
its a sad truth that you really need to use assembly to get anywhere with game making on old machines for the most part.
I don't disagree with the "6502 isn't C friendly." Mostly because I don't have the technical knowledge to even understand it. However, I disagree with that statement. Aside from my 1 zsort issue, I've not experienced slow down on the system, despite being 100% in C.
I mean, hell, Alter Ego for the NES was written completely in C (from my understanding). That's a fun game, and runs just fine.
You'll never make a bullethell fast-paced shooter on the system in pure C, but C is plenty good enough to make a fun, exciting experience.
Seeing as we have what, 3 active *game* programmers (You, me, Punch) and a few new people, at least 33% (LOL!) of the older active devs are completely reliant on C. That said, Catastrophy hasn't shown an update in quite a while, because Gredler really wants to keep some things we've developed under lock and key. It's far from the same game we've shown in the past, and I think it will excite people once we release our trailer.
Further, due to... IP issues (lol... ridic, right?), I can't be public about my other project. I've gotten good reviews from people who have played it, however.
|
|
|
Post by dshadoff on Jan 12, 2020 18:21:09 GMT
It depends on the kind of game you want to write, too. Scott Adam's Adventure (text) doesn't need speed at all. But the PC Engine was really about fast-moving arcade graphics, with a lot of shooters... which is where we're coming from.
|
|
|
Post by Arkhan on Jan 12, 2020 18:28:25 GMT
For the record, I didn't really believe in the concept of HuC when David Michel came up with it - for pretty much the same reasons that you state. 'C' was basically made for 16-bit (and up) processors; it produces bad code on 8-bit processors, and promotes some bad habits on processors with limited registers. David and Zeograd came up with a couple of interesting demos and persuaded me, explaining that it was a faster way to write some basic code, but that people would want to do better, and learn assembler for the critical portions... which made sense to me at the time. I enjoyed coming up with solutions to the tricky bits (system startup, CD usage), and considered them proof-of-concept code. But mostly it's sat in its original state for years at a time, without particularly heavily usage, and it just feels a bit weird for something so under-utilized, for an architecture with so little information known to the public, to be criticized for its lack of development. Like mocking Francis Crick for discovering the helical structure of DNA back in the 50's, but not having sequenced it at the time. The disjointed documentation was/is my real gripe honestly. I went into it knowing that C on a 6502 based machine is going to be dumb. I already used C on a C64 to learn that. The overlay thing is another one of those wonky things that isn't bad, and isn't good. It's almost good. but with the lack of anyone using or dealing with it, I can see why it never went anywhere. PCE has generally never had a community that actively does much outside of tinker and show POC stuff that ends up going nowhere. If the overlay thing could generate the data overlays the documentation claims can be used, ISOLink in and of itself, outside of the.... 64??? overlay limit would be fine probably for pretty much any homebrew project. Unless you go fucking nuts with sound effect VOX files and use all the entries for those. I don't disagree with the "6502 isn't C friendly." Mostly because I don't have the technical knowledge to even understand it. However, I disagree with that statement. Aside from my 1 zsort issue, I've not experienced slow down on the system, despite being 100% in C. I mean, hell, Alter Ego for the NES was written completely in C (from my understanding). That's a fun game, and runs just fine. www.youtube.com/watch?v=XN-Z8S_MIH4You'll never make a bullethell fast-paced shooter on the system in pure C, but C is plenty good enough to make a fun, exciting experience. See the thing is though, NES has a better C toolkit in general mainly due to more exposure, and Alter Ego, from what I remember reading, was written specifically with C in mind and exists ported to various machines. It's a fun game, but it isn't exactly complicated. You can make a neat game in HuC, but once you get into complicated stuff, it will bog down. Your game from what I saw, has alot of art and visual flair but when you break down what it's actually doing, it's not doing much at a time. From what I understand, you generally have been running into space problems, not speed problems. You have a problem that would exist in assembly too. This lack of stuff going on isn't a bad thing. Bonk 1 for example is real similar. There's never that many things on screen if you stop and look. It also actually dynamically loads enemies in and out of VRAM if they don't/wont exist anymore. That way it can use the same sprite pattern locations and the code's probably really generic. But there's never a ton of shit going on. Contrast that with Insanity for example. Yeah the game is awful looking because I can't draw, but ..... Every sprite can collide with every other sprite. Every sprite can also collide with the walls. So when you have 10 robots that can each fire a lazer, the player, and your shot... you have 22 sprites that all need to see if they are touching each other, or a wall. That's a lot of bullshit to do, and it 100% bogs down in C because of the lack of registers and generic nature of the code a C compiler outputs. It's not able to be smart enough to optimize some bits and save / reuse data. Another example would be Atlantean's stupid radar. That stupid thing isn't fast. In C or ASM really, lol. You are updating tiles like bitmaps. It's not a fast thing to do. A few goony little things can suck up resources, so it's best to not have them wasted on C code that's slow only because it's compiler-created and non optimized. I'd be curious how Atlantean chugs along, or the non optimized Insanity thru HuC 3.99 but last time I tried building in it, it exploded and went nuts so I never got to see. I'm legit curious, but not enough to use alot of my time checking into it lol.
|
|
|
Post by DarkKobold on Jan 12, 2020 18:46:16 GMT
You can make a neat game in HuC, but once you get into complicated stuff, it will bog down. Your game from what I saw, has alot of art and visual flair but when you break down what it's actually doing, it's not doing much at a time. From what I understand, you generally have been running into space problems, not speed problems. You have a problem that would exist in assembly too. This lack of stuff going on isn't a bad thing. Bonk 1 for example is real similar. There's never that many things on screen if you stop and look. It also actually dynamically loads enemies in and out of VRAM if they don't/wont exist anymore. That way it can use the same sprite pattern locations and the code's probably really generic. But there's never a ton of shit going on. Contrast that with Insanity for example. Yeah the game is awful looking because I can't draw, but ..... Every sprite can collide with every other sprite. Every sprite can also collide with the walls. So when you have 10 robots that can each fire a lazer, the player, and your shot... you have 22 sprites that all need to see if they are touching each other, or a wall. That's a lot of bullshit to do, and it 100% bogs down in C because of the lack of registers and generic nature of the code a C compiler outputs. It's not able to be smart enough to optimize some bits and save / reuse data. Another example would be Atlantean's stupid radar. That stupid thing isn't fast. In C or ASM really, lol. You are updating tiles like bitmaps. It's not a fast thing to do. A few goony little things can suck up resources, so it's best to not have them wasted on C code that's slow only because it's compiler-created and non optimized. I'd be curious how Atlantean chugs along, or the non optimized Insanity thru HuC 3.99 but last time I tried building in it, it exploded and went nuts so I never got to see. I'm legit curious, but not enough to use alot of my time checking into it lol.
I agree completely, I write my games with that philosophy a lot. You can do a lot of cool things with very little. The one time when we do bog down - Zsorting up to 14 different objects on screen, it bogged way the hell down, and required ASM. However, I also made sure I don't do what you suggested back in #derpchat - I made sure that only the things that can interact (6 with 4, 6 with another 4, 4 with a different 4, etc) check hit boxes each frame. So, very rarely am I doing a ton of checks per frame. The way I wrote it minimizes the "bullshit to do" per frame. Enemies can't hit other enemies, players can't hit other players, certain projectiles only hit one or the other. Etc. My code is probably stupidly complex, but the actual shit being executed per frame is minimal.
|
|
|
Post by Arkhan on Jan 12, 2020 18:59:47 GMT
Yeah, if you minimize what you ultimately have to do, you can get away with slower code because it won't bog down.
Insanity ran at like -14 FPS with 10 robots and the player even before all the robots were shooting, using just C.
It was a product of array access and stack variables and such making it all suck in addition to the overhead of checking for tiles.
|
|
|
Post by turboxray on Jan 12, 2020 20:28:14 GMT
Milkford was developed for 8bit systems to get better performance. It's higher level than Assembly, but little lower than C. Someone made a quick nes game-demo using it. 6502 is inherently not C friendly. Well to be honest, it's not entirely performant friendly in ASM right out of the box either hahah. There's still a somewhat-decent gap between un-optimized optimized code. And those optimizations you made for zsorting and such for HuC, are still applicable optimizations for ASM. It's not always about local cycle counts.. it's the higher level optimization as well - designing data structures and higher level design inconjunction with ASM optimization. I mean in relation to the bullet-hell reference.
|
|
|
Post by Arkhan on Jan 13, 2020 4:51:01 GMT
yeah but crappy assembly will still run faster than good C, lol
|
|
|
Post by elmer on Jan 13, 2020 7:02:04 GMT
Fair enough, it is tied to HuC, and I'll explain the reasons: 1) There was nobody back then (besides the authors of the compiler) who had any intention of writing in assembler. I participated in HuC thinking that it would be the gateway to bring "regular gaming programmers" (in the context of the 90s) to the point of becoming more comfortable with assembler. Well, it may have taken a couple of decades since you did the work, but IIRC, Arkhan has actually taken that step, so your concept has been proved out, even though you might have wished for more folks to take that step. ...To assume that anything more than the above should have been created is to assume that there was more time available, more developers involved, and more information already known about the system. In case I've not been clear enough recently ... I find what you guys did in creating HuC to be pretty-darned-amazing, even more so with the limited information and technology of the times. The existence of your work is one of the primary reasons that I am here and contributing to stuff today, without it, I just wouldn't have had the patience to develop it all from scratch myself. That doesn't mean that I agree with every design choice that was made, after all we're all different individuals with our own unique experiences and preferences ... but I love that you guys actually did make and follow through with your choices, and successfully created something that was both tough to make, and still valuable 20 years later on. 4) As turboxray implies, anybody sufficiently adept at assembler would probably want to build their own tools. And a secondary goal of HuC was to provide a commented, working code example for them. I totally agree with the second part, which is why I believe that releasing source code for things is essential (even though I personally prefer to delay until I am reasonably happy with something before releasing it). As for the first part, "yes", experienced programmers often like to customize their toolchain, and/or develop their own tools. But, IMHO, most people, however experienced they are, don't want to keep on re-inventing the basics, just to fill a void. For instance, I don't believe that there are a queue of developers who want to write yet-another assembler. In the same vein, I really don't think that most people want to develop their own tool to assemble an ISO out of a bunch of files ... it's just too basic of a requirement, and something that programmers find boring. So ... I've taken your isoLink source, and extended it just a little (the changes are fairly minimal). Since I was playing around in there, I also made a couple of small modifications to the HuC overlay loading, while trying to be careful not to break things. The upshot is ... HuC can now include 98 overlays, up from the previous limit of 49, although HuC is still limited to an ISO size of 128MB (which doesn't seem like it is a problem in real practical terms). Assembly-language developers can now either set the IPL parameters on the isoLink command line, or they can define their own replacement IPL sectors (if they use pceas and incbin the original IPL data), and so create a completely custom boot that alows them to use the unused space in the 2nd boot sector. In all three of the different situations, isoLink now saves a 254-file directory into the unused last 512-bytes of the 1st boot sector. The directory can address an ISO size of 256+MB. Assembly-language programmers can retrieve the directory directly from the PCE's memory at $2E00..$2FFF when their initial program runs, because the BIOS IPL boot system will *always* load it there and leave it intact during the boot process. The changes are checked into github, but I'm not going to share a "release" build unless someone indicates a specific desire for one.
|
|
|
Post by Arkhan on Jan 13, 2020 7:09:26 GMT
Is there a way to coax a data-only overlay with HuC in any capacity, currently?
If not, the overlay process is still not as flexible as it needs to be for CD_LoadVram, and whatnot
|
|
|
Post by elmer on Jan 13, 2020 8:11:00 GMT
Is there a way to coax a data-only overlay with HuC in any capacity, currently? If not, the overlay process is still not as flexible as it needs to be for CD_LoadVram, and whatnot Can you provide an example of something that doesn't work in the way that it is supposed to ... or heck, even just as you wish it would? As I have said before ... I don't use HuC, so I'm a lousy person to determine what is broken, or could just be better. Uli made a *lot* of changes to improve HuC, and he provided a testsuite so that regressions and problems could be identified, even including an overlay test ... but there are no examples for data overlays. A look at the HuC source code suggests that data overlays should just be assembled in pceas with "-raw", or included as binary files if you use an external converter. Beyond that, I have no idea how they're supposed to be used. Have you ever seen any examples?
|
|
|
Post by Arkhan on Jan 13, 2020 8:19:28 GMT
Pure, raw data overlays with no code are to be used to load cd data to vram for example.
There are no examples. Just the api in huc docs or archaic pixels.
If you want to create an overlay thats just graphics, whats the recommended approach?
Just hand concatenate them and isolink them in?
Since huc didnt come with a pcx to vdc converter, im not surprised this step is wonky.
|
|
|
Post by elmer on Jan 13, 2020 8:44:54 GMT
If you want to create an overlay thats just graphics, whats the recommended approach? Just hand concatenate them and isolink them in? Since huc didnt come with a pcx to vdc converter, im not surprised this step is wonky. Well, I believe that if you want to load data from the CD directly into VRAM, then "yes", that would be both the method and the overlay load function that you're looking for. It's just a wrapper around the BIOS's CD_READ function call that retrieves the sector address from the overlay "directory" that isoLink injects into the HuC program. You would either create the VDC-ready data using an external toolchain, or by using "pceas -raw" and "incchr" or something like that. The overlay function that loads data into RAM is a bit more of a mystery to me, since it *seems* to load into the data area just-after the program banks in your HuC file, and I have no idea how you would identify that location inside a HuC program.
|
|
|
Post by Arkhan on Jan 13, 2020 9:00:05 GMT
But using pceas means you aren't using huc, lol. thats the issue.
|
|