|
Post by spenoza on Jul 7, 2022 13:35:11 GMT
I wouldn't start with the master system one. I would take the entire stage layout of the Genesis version, and shrink it to 80% horizontally to correct for PCE's 256px PAR (pixel aspect ratio) Wouldn't this mess with chopping the scene up into tiles and objects? 80% of a 16 or 32-pixel sprite, for example, is not a proper sprite size on PC Engine.
|
|
|
Post by SignOfZeta on Jul 7, 2022 14:39:49 GMT
I agree with the excellent arguments being made that work on this scale should be done to make something more useful.
Also I’d like to mention something that maybe some people don’t understand which is that when a 1st party makes a big time game like Sonic the Hedgehog they do things on purpose to show off the machine and to do things other machines have a hard time doing. When they made PCE games they did the same thing, look at all the color, for example. The PCE has a lot of shooters, the Bandai Playdia doesn’t. Do what makes sense. Stunt programming is cool but only sometimes results in a good game.
So don’t waste time porting Super Mario Kart to Game Gear, or whatever. It’s like asking Vin Diesel to write a novel.
|
|
|
Post by elmer on Jul 7, 2022 15:53:20 GMT
One of things I recall him saying was that the Turbo can't do tile or Sprite flipping which adds to the resources that are needed to make a Sonic game. Errr ... sure the PCE doesn't support tile flipping, but it certainly does support sprite flipping! This seems like a total waste of time, just to prove the PCE could do it. And why? To play Sonic on a 2 button controller instead of 3 buttons? While I agree with your conclusion, I do feel that it needs to be pointed out that the PCE has both 3-button and 6-button controllers available. Also I’d like to mention something that maybe some people don’t understand which is that when a 1st party makes a big time game like Sonic the Hedgehog they do things on purpose to show off the machine and to do things other machines have a hard time doing. ... Stunt programming is cool but only sometimes results in a good game. I 100% agree with this. Sonic is designed to show off the two fast-scrolling background layers on the Genesis hardware. IMHO any attempt to use clever PCE programming tricks to try create a Sonic clone on the PCE will just fall flat, because it will never be *identical*, and so the Sonic purists will always have something to point out as "lesser", even if that is only the resolution. If you want to see Sonic on NEC hardware then it should, IHMO again, be done on the SuperGrafx, which was designed to display the extra layer without compromise. Then you'd be able to up the resolution to 352x224, and show it all running as fast as the Genesis ... and it wouldn't require years of tedious custom coding to try to get around the PCE's single-layer limitation. Even then ... as a programmer, I'd say that it would probably be far more interesting to work on something new-and-improved, rather than just trying to clone another console's signature-game. Because no one has asked about using it haha, so there's no rush to make it public. I even asked around.. people directly (privately), got an "ehh.. mayyybe". I mean, that's totally fine. I made it for my own projects first and foremost, but I mean if easy parallax for the PCE doesn't get people hyped about PCE dev.. I'm not sure what else will. Kind of got the feeling anything else related to Huc/TGDK will be the same. So it's more like, is HuC/TGDK more of a distraction to what I should be doing? What you should be doing is what you WANT to be doing. Life is too short, and you have too little free time, to do otherwise. If that is tools for the community, then great! If it's something else, then that's also great! But what I will say about tools, especially for the complex piece of "easy parallax" code that you wrote and intimately understand the techniques and limitations of ... documentation, examples, and timely support are all critical. Most of the people who *might* be interested in your code are not as technically skilled as you, and they definitely haven't lived through its creation process, and so won't understand its usage/limitation as well as you do. 0x8bitdev has been a shining example of this with MAPed and SPRed ... and because of this, we're seeing them being used, and I can only assume that they'll continue to be used.
|
|
|
Post by hyperfighting on Jul 7, 2022 17:33:30 GMT
turboxray Just chiming in here I would love to experiment with an example of "easy parallax" also I recall you mentioned you have some cool effects EX: Chrome Bomberman style etc. If any of that stuff is avaliable I would love tinker.
|
|
|
Post by 0x8bitdev on Jul 7, 2022 18:10:28 GMT
Initially MAPeD/SPReD were NES tools for private use. I just wanted to understand the NES hardware, couldn't find any similar tools, and decided to write my own. But after I realized that they quite usable and I can't just leave it to myself and forget it. It might come in handy for someone. And it doesn't matter to whom. Yes, I had to write some documentation so that someone else could use them besides me. turboxray You made different changes for HuC. As far as I understand, only you know all the details. But I don't even know what to ask you to figure it all out. This is just an example of how you might think that no one needs your work. But the problem is that people are very vague about what they will have to deal with. Questions will arise when there is at least some documentation. Once you have your engine with samples and docs, someone will decide to use it.
|
|
|
Post by DarkKobold on Jul 7, 2022 19:31:46 GMT
Most of the people who *might* be interested in your code are not as technically skilled as you, and they definitely haven't lived through its creation process, and so won't understand its usage/limitation as well as you do. I'd also like to note that people turboxray reach out to privately are likely to be people who are deep in the scene, like dshadoff or mooz, not some newbie coder. Those people are obviously less likely to be enthusiastic about an easy parallax engine.
|
|
|
Post by dshadoff on Jul 7, 2022 20:06:56 GMT
Well, there is always something to be said about a ready-made example - even for a person who is capable of creating it themselves - as a means of saving time and energy.
|
|
|
Post by turboxray on Jul 8, 2022 16:47:08 GMT
I wouldn't start with the master system one. I would take the entire stage layout of the Genesis version, and shrink it to 80% horizontally to correct for PCE's 256px PAR (pixel aspect ratio) Wouldn't this mess with chopping the scene up into tiles and objects? 80% of a 16 or 32-pixel sprite, for example, is not a proper sprite size on PC Engine. No. A sprite doesn't care if you use all or just some of the pixels. Same goes for meta-sprites. As far as tiles, or rather sections of the map, for example if I had a pop-out ledge that was 112 pixels wide and it's now 89.6 pixels via reduction - I can either chose to extend it to 96 pixels or clip it to 88 pixels, if I really wanted to be pedantic about it I could use sprites to gain back a few pixels (not worth it IMO tho). I mean this is a port. It was never going to be exact anyway. I would make slight changes here and there. Look at the SNES port, it kept everything identical but now you're missing like 25% of the horizontal screen. In that respect the SNES port isn't exact. But, you have all the assets you need to go either way; with PAR and without PAR correction. No need to start with the master system version unless you're trying to do a modified port of that. Sure, but there's no guarantee a homebrew game is going to be good just because it didn't focus on pushing the system. I'd rather have a game that pushes the system and is below average in fun-factor, than a plain game that is below average in fun-factor. I mean, get yourself a person who can program and push the system.. to design the game engine, and get yourself a person who knows how to do good game design/etc. Problem solved. I'm not sure how hard it is to import a library. Use a function to point to a map(i.e. load_map(label) or whatever), and simply do map_position(x,y). That's literally all there is to it. The code I created might be complex, the API to use it is not nor does it require you to understand anything more than the API itself. All that is moot anyway, because the people that I figured would be interested in it - never bothered to show interest or wanted to test it out, so none of that even came into question. No butthurt - I just find that bizarre is all. I mean yeah, my use of the engine will be above and beyond (like streaming in meta-objects), but general use is pretty easy (including just making the map). Anyway, we'll see when I make a beta version public and hopefully actually get some feedback. Well, it should be for PCE fans. Who cares what purists or whoever else wants to complain or whatever. Do you want to see the PCE do some amazing parallax? The answer is generally yes. Imagining other systems games, on the PCE, is no different than imaging arcade ports on the PCE. There's nothing stoping you from re-imaging Greenhill zone with better graphics and colors too. The Megadrive is getting a Symphony of the Night PlayStation port, and I don't see purist complaining about it - it's obviously cut back. I haven't seen anyone complaining about it. Just the opposite.
|
|
|
Post by turboxray on Jul 8, 2022 17:03:36 GMT
turboxray You made different changes for HuC. As far as I understand, only you know all the details. But I don't even know what to ask you to figure it all out. This is just an example of how you might think that no one needs your work. But the problem is that people are very vague about what they will have to deal with. Questions will arise when there is at least some documentation. Once you have your engine with samples and docs, someone will decide to use it. There's no documentation because it's not really publicly released. And it also requires you to be extremely familiar with how PCEAS works with HuC, and how HuC lays things out - all under the hood. I mean people are free to use it, obviously, but I needed it first and foremost for my sound engine HuTrack - and a few other libraries. That's why it's there. The changes I made were pretty minimal. It's mostly just the ability to include/overriding library stuff without resorting to hacking startup.asm, and a reserved asm bank area to keep HuC from trampling on it (because it will!). No one has approached me with how to use those features, because I didn't make it publicly known haha. Which is why there isn't any documentation on it. You're the first person I know of that asking about it. It's functional and in the HuC release, but right now I need it in there for people to test out HuTrack. When I get some down time, I can write a few examples of how to use it. I'm sure Elmer and Dshadoff can help as well. Once you get a basic idea of what I added, it's pretty minimal to whip up some examples and docs.
|
|
|
Post by spenoza on Jul 8, 2022 17:23:06 GMT
Wouldn't this mess with chopping the scene up into tiles and objects? 80% of a 16 or 32-pixel sprite, for example, is not a proper sprite size on PC Engine. No. A sprite doesn't care if you use all or just some of the pixels. Same goes for meta-sprites. As far as tiles, or rather sections of the map, for example if I had a pop-out ledge that was 112 pixels wide and it's now 89.6 pixels via reduction - I can either chose to extend it to 96 pixels or clip it to 88 pixels, if I really wanted to be pedantic about it I could use sprites to gain back a few pixels (not worth it IMO tho). So tell me how well you think it will go when trying to preserve important patterns and textures, so important to the look of Sonic, using 8x8 tiles which have been shrunk 80%? This is why I think shrinking everything 80% is folly. Keep most of the repeating tiles the same, at least, to preserve the general look and design feel, and then just shrink elements like loops and bridges and whatnot. Hand-adjustment is the only way things will look good and be manageable.
|
|
|
Post by turboxray on Jul 9, 2022 21:52:31 GMT
No. A sprite doesn't care if you use all or just some of the pixels. Same goes for meta-sprites. As far as tiles, or rather sections of the map, for example if I had a pop-out ledge that was 112 pixels wide and it's now 89.6 pixels via reduction - I can either chose to extend it to 96 pixels or clip it to 88 pixels, if I really wanted to be pedantic about it I could use sprites to gain back a few pixels (not worth it IMO tho). So tell me how well you think it will go when trying to preserve important patterns and textures, so important to the look of Sonic, using 8x8 tiles which have been shrunk 80%? This is why I think shrinking everything 80% is folly. Keep most of the repeating tiles the same, at least, to preserve the general look and design feel, and then just shrink elements like loops and bridges and whatnot. Hand-adjustment is the only way things will look good and be manageable. I wouldn't start with the master system one. I would take the entire stage layout of the Genesis version, and shrink it to 80% horizontally to correct for PCE's 256px PAR (pixel aspect ratio). This will give you the correct aspect ratio, because when the real PAR for low res 256px kicks in, it will be correct to the Genesis version (for NTSC, not PAL). From there, using it as a base, start reworking the stage "tiles" as chunks, in the layout. Start with simply blocks, and then refine. TiagoSC, who did the SNES port, should have taken this route. Instead he just used all the assets as-is of the Genesis port. Edit: All the Sonic Advance games on GBA would be even easier to port.
|
|
|
Post by spenoza on Jul 9, 2022 23:36:30 GMT
Ok, I missed that on my first pass: mea culpa.
Would be totally on-board with the Sonic Advance level designs. They’re solid games.
|
|
|
Post by crisgenjin on Jul 10, 2022 14:52:58 GMT
I think the question needs to be asked though: Do you really want to see a Sonic port/demo of Green Hill Zone on the PCE, or would you rather have a new Bonk demo that does all of this kind of stuff??? Because after a Green Hill Zone demo, which would be definitely nice, then what? The whole game? People are going to eventually forget about it (the novelty wears off), and/or demand you finish making the game/port. I mean, the game already exists on the Genesis. Outside a nice tech demo, I rather see something like above methods applied to a new Bonk style game (or something original). And this is why I personally have had to stop myself from doing a Sonic demo with all the above mentioned stuffs as much as I would love too (given I have severely limited free time). I learned from the NES2PCE stuff, which took up a lot of time, is in the end just novelty. I'll be honest, there's a ton more important stuff that really could use your skill set. This seems like a massive distraction from all of the big plans, like HuTrack, TGDK, and mapper support in HuC/TGDK. This seems like a total waste of time, just to prove the PCE could do it. And why? To play Sonic on a 2 button controller instead of 3 buttons? It wouldn't actually use any of the advantage of the TG16, because you aren't going to redraw the art to use more colors. You've already demonstrated an engine that uses parallax, but no one can use it because it isn't released. I'll be honest too, what the hell has the number of buttons on the controller gotten to do with the feasibility of a port? The Sonic games on Mega Drive pretty much rely on a single button for movement. Maybe not Sonic 3 & Knuckles, I'm not sure on that one. But even then...the Sonic 1 8-bit port on the freakin' Commodore 64 only requires a button too, and you could use those old crappy Atari joysticks with the 9-pin D-sub port
|
|
|
Post by DarkKobold on Jul 11, 2022 20:36:28 GMT
I'll be honest, there's a ton more important stuff that really could use your skill set. This seems like a massive distraction from all of the big plans, like HuTrack, TGDK, and mapper support in HuC/TGDK. This seems like a total waste of time, just to prove the PCE could do it. And why? To play Sonic on a 2 button controller instead of 3 buttons? It wouldn't actually use any of the advantage of the TG16, because you aren't going to redraw the art to use more colors. You've already demonstrated an engine that uses parallax, but no one can use it because it isn't released. I'll be honest too, what the hell has the number of buttons on the controller gotten to do with the feasibility of a port? The Sonic games on Mega Drive pretty much rely on a single button for movement. Maybe not Sonic 3 & Knuckles, I'm not sure on that one. But even then...the Sonic 1 8-bit port on the freakin' Commodore 64 only requires a button too, and you could use those old crappy Atari joysticks with the 9-pin D-sub port Eh, that was more just to point out that moving from one 16 bit system, with fewer colors but more parallax, to a system with more colors but less parallax, wasn't really doing much. The buttons on the system was sort of a trivial point about it to emphasize the lack of fundamental gameplay changes. The ports that are interesting to me are the ones that either way backport (Final Fantasy 7 NES, Halo Atari 2600, etc) or re-releases that up-res and do something with the underlying game. This is moving from one 16-bit system to another. While the underlying technical feat would be amazing, it wouldn't fundamentally change the fact that you're just playing Sonic 1 on a different 16-bit system.
|
|
|
Post by crisgenjin on Jul 16, 2022 15:51:29 GMT
I'll be honest too, what the hell has the number of buttons on the controller gotten to do with the feasibility of a port? The Sonic games on Mega Drive pretty much rely on a single button for movement. Maybe not Sonic 3 & Knuckles, I'm not sure on that one. But even then...the Sonic 1 8-bit port on the freakin' Commodore 64 only requires a button too, and you could use those old crappy Atari joysticks with the 9-pin D-sub port Eh, that was more just to point out that moving from one 16 bit system, with fewer colors but more parallax, to a system with more colors but less parallax, wasn't really doing much. The buttons on the system was sort of a trivial point about it to emphasize the lack of fundamental gameplay changes. The ports that are interesting to me are the ones that either way backport (Final Fantasy 7 NES, Halo Atari 2600, etc) or re-releases that up-res and do something with the underlying game. This is moving from one 16-bit system to another. While the underlying technical feat would be amazing, it wouldn't fundamentally change the fact that you're just playing Sonic 1 on a different 16-bit system. I'd argue that the FF7 NES demake, both in its original bootleg form and with the fan-made rom hack, is pretty shit overall. The console's color limits make everything look garish and messy, the graphics are barely a step above Final Fantasy 3 (Or maybe even worse?), the run button is unreliable, fights are slow and the music makes me want to cut my ears off. It's clear they haven't focused on the finer details lmao
|
|