Anyone care to check something for me. . . .

[Tanooki]

9 minutes ago, WavyGravy said:

Well, when discussing the Sega CD vs SNES, he conveniently never mentioned that the 32X can use the SCD, and that is indeed Genesis hardware, therefore, the Genesis still beats out the SNES in FMV potential. And has done since 1994.

 

Can't imagine why that wouldn't have been brought up.

Lies, conspiracy!  You're making it up, you know you can't use those together it's just a myth 32x kids like to make up for feeling jilted by Sega.  Yet another wavy tin foil moment in time.

Inceptional is watching you CLOSELY.

[WavyGravy]

Eh, he watches a lot of RGME videos closely and still gets a lot of stuff wrong, I'm not that worried about it.

[TrekkiesUnite118]

38 minutes ago, WavyGravy said:

Well, when discussing the Sega CD vs SNES, he conveniently never mentioned that the 32X can use the SCD, and that is indeed Genesis hardware, therefore, the Genesis still beats out the SNES in FMV potential. And has done since 1994.

 

Can't imagine why that wouldn't have been brought up.

32X doesn't even need the Sega CD. It can beat it with just a mapper:

 

[WavyGravy]

It's probably quite a bit better with just the mapper, no? You wouldn't be constrained by the speed of the drive at that point, at least.

[turboxray]

So.. this is such a contrived demonstration and comparison.. faceoff or whatever. Of ALLLL the things the snes could do over the PCE and MD, and inceptional chooses this??? Seriously? Anyone who's played a snes game, and has seen some of the graphics pushed in mode 1 (3 layers) is going to look at this and go... why the fuck are the fore ground layers limited to NES 2bpp color?! Literally, you have 200+ color single plane image juxtapose against NES graphics layer.. and that's supposed to impress? I don't know about you, but what I don't expect from my snes ..MY SNES.. is some NES looking graphics. So you gained a few extra colors.. and scarified two beautiful layers and a 3 layer for this. Look.. the 256 bpp mode is clearly meant display pics or graphic novel type games. Why? Because it EATS the ever living shit out of vram. You have almost no room for sprites, and one addition layer that's literally NES level graphics. No one in their right mind would make a platformer in this mode.. just because you can, doesn't mean you should. In the demoscene circles, it's like that's kinda neat.. everyone else - mode 1 snes games look miles better than that.. and for good reason.

 

This is just a moronic challenge. Out side of what I've already said.. here's a few other reasons.

 

 The PCE and Genesis don't have 8bpp modes. Do you know what that means? 1) there's literally no equivalent, so there's zero reason to confine to the same limitations (and even resolutions at this point). 2) The SNES is vram starved in that mode.. the PCE and MD are not. There IS nothing stopping me from implementing a sprite obj layer, like I did on the PCE, on the MD.. and get 3 layers going on. I mean the vram is even there for it.

 

So let's break down the SNES example, for which his video is bunk or near bunk. His video is showing a 256px mode on the SNES.. no clipping. So that means in order to scroll, you need AT LEAST as 64x32 wide tilemap. Since inceptional has already admitted he's trash as simple arithmetic, let me break it down for you:

 

His demo has a 256x224 8bpp image wide screen, scrolling horizontally. That means at ANY given time, he need to have (256+8)x224 image detail in vram.. at any given time (redundancy for inceptional to take note). That takes up 264x224 = 59,136 bytes of vram. For the sake of optimization, I'm going to assuming he chose to put main tilemap in 16x16 mode (and not the normal 8x8 mode) for the 8bpp layer and 8x8 mode for the 2bpp layer (because why do you want to have all 4 meta tiles to be a single palette for a 2bpp tileset). 32x32 (as 16x16) is 512 bytes. Because the tilemap is in 16x16 mode, it occupies 64x64 tile space. Just for clarity here, 32 tiles x 8 (tile width) = 256 pixels. 32 tiles x 16 = 512 pixels. So a 32x32 map as 16x16 entries, is a 512x512 pixel map. If the screen is 256x224, you have enough room outside the main area to buffer in off-screen incoming changes. This is pretty basic retro console stuff. You need a map that is larger than the screen in order to scroll without artifacts on the edge of the screen. So 512 bytes for the large map that can handle the 8bpp layer. For the 2bpp layer, you'll need a 64x32 map. That costs 64x2x32 = 4096 bytes. So what are we up to? 63,744 bytes. Keep in mind there is only 65536 bytes. So you have 1,792 bytes free. WTF are you going to do with 1792 bytes? Since he has almost NO detail in his demo, let's assume he only need 70 2bpp tiles for that ooh-so-spectacular-detail on the additional layer (he has capital ASCII set, full 0-9 digital chars too, small "x", the coin in the stat bar, etc). So that's 70 x 16 (16byte since these are 2bpp tiles) = 1120 bytes. No we're down to 672 bytes. If he uses 16x16 cells for sprites.. that leaves him with only 5.25 cells for unique sprites. Let's assume he actually knows what he's doing here (lolol), and has opted for the 8x8 paired with 16x16 sprite mode for the screen. That way he can save a little bit of space for the mushroom sprite (the top has is mirrored, so he saves one 8x8 cell). the goomba takes up 3 sprites (at 8x8).. that's 96 bytes. Now we're down to ..what exactly... 576 bytes! Even if you perfectly aligned some of the Alucard sprites, as-is, to perfect boundaries.. the frames I looked at ramp up to 700bytes. Ahh... looks like you ran out of vram! Math is soo mean. But let's magically pretend you somehow scrounged up those free bytes in vram and could display Alucard.. you'd literally be VRAM full. Nothing else.

 

 So yeah, you have this beautiful background.. and everything else around is hot garbage. Mean while the PCE and MD don't have an 8bpp mode tearing through vram... so they're free to ACTUALY have sprites on screen and graphics that doesn't look like something straight out of the NES.

 

 As Trekkies pointed out, I highly doubt you took into account that the the entire SNES palette is 256 color entries. Normally 128 is for BGs and 128 is for Sprites. Bit in 8bpp palettized mode, it eats into some or ALL of the sprite entries. So you need to dial it back for sprites, and you need to do the same for the 2bpp BG layer. Alucard is 15 colors and the goomba needs at least 3 colors. The brinks, coins, clouds, grass... need 4 palettes of 3 colors each.. that 12 colors. So you need to strategically reserve 30 colors from that 256 color palette (and in the right slots). Thank god you didn't put a koopa in there!

 

 This is the kinda crap a mockup doesn't enforce on you, especially when you don't have a firm grasp on the hardware and fundamentals. Annnddd to put this into further context.. inceptional is OBSESSED with showing a full 256x224 or 256x240 8bpp image (because of some fanboi insecurity about the snes being infamous about needing clipped displays). I told him multiple times that since vram is super tight when dealing with all unique tiles for images like he's posting, that if you clip some of the display... you don't need to hold as much in vram and give yourself AT ALEAST a little bit more breathing room. Ohh no, that's too much of a compromise and I'm just trying to trick him. He's literally an idiot.

 

 So, do I get to do the same? Can I post mockups that are inaccurate for this "battle" of the systems? Is the 8bpp mode useless? No. Is inceptional and idiot? Of course. You would never use it this sort of way. I would literally use this for a Monkey Island kind of game. And I would letter box the shit out of it so I'd at least have some vram free for sprites and animation. But this guy... I swear.

 

 But to re-iterate.. you don't even NEED this contrived trash of an example of you wanting to shame the MD and PCE in the graphics department. Mode 1.. literally mode 1.. 3 by layers, full support for sprites, 2 layers being 4bit with as 32k main palette.. transparency, windowing, etc. You DON'T need to try this hard. He's only trying this hard because he thinks he came up with some new novel use of 8bpp mode..as if no one else EVER thought about this.. and he's going to set the world a blaze... with NES graphics on the foreground layer. shake-my-motherfucking-head. Some people's children, I swear..

 

Edited August 27, 2023 by turboxray

[smds]

37 minutes ago, turboxray said:

There IS nothing stopping me from implementing a sprite obj layer, like I did on the PCE, on the MD.. and get 3 layers going on. I mean the vram is even there for it.

This is what I'm doing in my VN Engine. I use the sprites as a third layer for the bottom text box and all the tiles it requires fits "neatly" in between the tables in VRAM:

[Kirk_Johnston]

Since it's Sunday, I thought I'd take an hour to add some extra colours into the Goombas just for fun, seeing as sprites have to be 4bpp anyway:

 

I couldn't be bothered recording footage of it again though, for now at least, so you're just going to have to imagine everything all layered up and moving around.

 

Interestingly, if you were to take a screen grab of this as it appears on a modern TV and then load it into say this tool and count how many colour the "SNES" was displaying there, it would be 168323 colours because of how the screen is blending some of the colours across pixels when upscaled to fit into the 4K resolution:

 

I'm obviously not doing that--that would clearly be a strange way to think about counting how many colours the "SNES" is displaying here--but just saying. And it's funny to think about it as such though, eh. 168323 colours on the "SNES"--wow! Hehe.

Edited August 27, 2023 by Kirk_Johnston

[TrekkiesUnite118]

1 hour ago, Kirk_Johnston said:

Since it's Sunday, I thought I'd take an hour to add some extra colours into the Goombas just for fun, seeing as sprites have to be 4bpp anyway:

 

I couldn't be bothered recording footage of it again though, for now at least, so you're just going to have to imagine everything all layered up and moving around.

 

Interestingly, if you were to take a screen grab of this as it appears on a modern TV and then load it into say this tool and count how many colour the "SNES" was displaying there, it would be 168323 colours because of how the screen is blending some of the colours across pixels when upscaled to fit into the 4K resolution:

 

I'm obviously not doing that--that would clearly be a strange way to think about counting how many colours the "SNES" is displaying here--but just saying. And it's funny to think about it as such though, eh. 168323 colours on the "SNES"--wow! Hehe.

So now you're going to need to reserve more colors for sprites and have less for your backgrounds since now your goomba needs more colors. You can't just throw those two layers at the tool with 256 colors think that's how it's going to work. Your 4bpp sprites and 2bpp layer need to have their colors in a 4bpp palette and multiple 2bpp palettes where they expect them to be in the order they expect them to be in. You can't just have their colors strewn about in the 256 color palette for the 8bpp layer. That's why you need to reserve a few palettes for them and cut back on the colors used in your 256 color image.

[Tanooki]

I love that huge post done explaining it at a level maybe a five year old toils get it…to then have Kirk accidentally(?) double down in his doofusness because of his petty ignore lock.

 

Read the reality, then the unreality. Then discount appropriately any future posts on the matter.  

[turboxray]

7 hours ago, smds said:

This is what I'm doing in my VN Engine. I use the sprites as a third layer for the bottom text box and all the tiles it requires fits "neatly" in between the tables in VRAM:

I meant like this:

 

You'd have to clip the display a little bit on the left and right, and manage the tilemap "bleed over" parts manually (which is easy.. just write the side columns to point to a blank tile). With up to a 32x32 size, you'll get enough screen coverage. If you need more, well.. MD allows reloading sprite table without turning off the display (as many times as you have active scanlines).

 

 

 And this is what inceptional purposely did on his demo, knowing I had this "sprite engine" on the PCE, with the "coins" comment... just to spite me haha. Hilarious because that literally doesn't stop the PCE version at all. To put that into context, let me quote inceptional on one of his own YT vids, "I can't even program on SNES and I came up with an idea for Mode 0 that goes beyond what 99% of actual SNES coders ever did"

 

Inceptional.. I know you're reading these comments hahaha.

Edited August 27, 2023 by turboxray

[Mittens0407]

4 hours ago, Kirk_Johnston said:

Since it's Sunday, I thought I'd take an hour to add some extra colours into the Goombas just for fun, seeing as sprites have to be 4bpp anyway:

This took an hour to do?

 

4 hours ago, Kirk_Johnston said:

Interestingly, if you were to take a screen grab of this as it appears on a modern TV and then load it into say this tool and count how many colour the "SNES" was displaying there, it would be 168323 colours because of how the screen is blending some of the colours across pixels when upscaled to fit into the 4K resolution:

In what world is that interesting or remotely important to anything discussed here?

[smds]

1 hour ago, turboxray said:

I meant like this:

 

You'd have to clip the display a little bit on the left and right, and manage the tilemap "bleed" parts over parts manually (which is easy.. just write the side columns to point to a blank tile). With up to a 32x32 size, you'll get enough screen coverage. If you need more, well.. MD allows reloading sprite table without turning off the display (as many times as you have active scanlines).

 

 And this is what inceptional purposely did on his demo, knowing I had this "sprite engine" on the PCE, with the coins... just to spite me haha. Hilarious because that literally doesn't stop the PCE version at all.

Yep I figured you meant it like that, It looks awesome!

My "3rd layer" is only 304x40 pixels and it doesn't need to move, so its very simple in comparison...

 

On the MD the main problem with a full 320x224 sprite layer would be scrolling that layer horizontally, since the maximum number of sprite pixels per line are limited to 320px (and I'm pretty sure offscreen pixels count towards that limit).

The only way for it to work without scrolling seams would be just like you said, to clip the screen to something lower than 320px wide or have a guarantee that there is always less than ~288 sprite pixels in a line (in the case of only using 32 wide sprites).

 

I don't know enough about the sprite system on PCE to compare... What are its sprite limits per scanline? Also isn't the PCE capable of some crazy screen resolutions? Does that affect the sprite limit in any way?

Edited August 27, 2023 by smds
304->288

[turboxray]

20 minutes ago, smds said:

Yep I figured you meant it like that, It looks awesome!

My "3rd layer" is only 304x40 pixels and it doesn't need to move, so its very simple in comparison...

 

On the MD the main problem with a full 320x224 sprite layer would be scrolling that layer horizontally, since the maximum number of sprite pixels per line are limited to 320px (and I'm pretty sure offscreen pixels count towards that limit).

The only way for it to work without scrolling seams would be just like you said, to clip the screen to something lower than 320px wide or have a guarantee that there is always less than ~288 sprite pixels in a line (in the case of only using 32 wide sprites).

 

I don't know enough about the sprite system on PCE to compare... What are its sprite limits per scanline? Also isn't the PCE capable of some crazy screen resolutions? Does that affect the sprite limit in any way?

 PCE, in low res mode, is 256 sprite pixels for the line buffer. This is because that's the fastest it can fetch sprite cells, which amount to that number. The VDC chip has three base resolutions. By that, I mean the video chip is literally clocked at three different speeds. This gives you the three different pixel widths... usually stated as 256px, 344px(or 352px), and 512px. So the video chip is fast enough to fetch more sprite cells at faster speeds relative to the chip mhz (dot clock) - but internally Hudson left the sprite line buffer at 256px. So it's ALWAYS 256px regardless of the "dot clock" pixel resolution. The PCE is flexible in that you can expand the graphics to show into overscan, or clip the display to something really narrow. I don't consider these settings "resolutions" per se.. as more of just clipping modes/setting. But yeah, it has fine clipping adjustment for the horizontal display (which the Bonk demo uses). PCE sprite cells are always 16x16.. and sprite sizes (i.e. hardware meta sprites) are based on this; 16x16,32x16,32x32,32x64,16x32,16x64. Basically like MD, but less total number of sizes and not based on 8x8 cells. Same principles too; fetch cells until you reach the line limit. Highest priority in the sprite table is shown, lowest gets dropped (if they all can't fit on a line).. and if the last one fits, but not all the cells.. then the remaining cells in that last sprite get dropped. Yadda yadda.

 

 So, for a normal 256px wide display, in order to have a seamless scroll of continues sprites across the screen - I would need 17 16px wide cells. But I can't fetch 17 sprite cells.. I can at most fetch 16. So I set the horizontal display to clip to something like 256-16 = 240px. 240 / 16 = 15. So a perfectly aligned contiguous row of sprites cells for 240px wide display is only 15.. and when you move just one pixel in.. 16 and no more (you drop the rest manually). So now I can continuously stream sprite cells from one side of the screen to the other, without break up. That's rule #1. Rule #2 - clip the sprites on the left side of the screen. In the Bonk demo, if I have a 32px wide hardware sprite, and it moves more than half way off screen to the left, I immediately convert to a 16px wide sprite and adjust for offsets. I do it for the right side too, but kind of unnecessary. 

 

 The PCE's cpu is fast enough that I rebuild and clip/crop all the sprites every frame for that layer. I don't cache any sprites, and I don't optimize to check only the sides. I decode the meta-object map and decode the meta sprites every frame. It's so stupidly fast that I haven't had a need to optimize it yet haha. So I know the MD will have no problem with this.

 

 Rule #3. Except for a few sprites where I want the player to be in front (and I have priority groups for sorting/rendering this out), I have the main blocks (don't have to be literal square blocks) always appear in front of the sprites (main character and enemies). This way, foreground layers never drop out. If the character or enemy is behind one of these foreground tiles, it'll dropout... but you won't see it because the dropout will be behind the foreground - it's beautiful.. sprite drop out that you can't see. You can see an example of this in the Bonk demo when he goes behind the large wall. This goes for projectiles, etc. And on the MD and PCE you can take advantage of this, if you're clever, and have a large enemy behind the FG layer.. or other sprites like columns or such. On the SNES, there's an odd thing with sprite rendering that gets in the way when you exceed the "cell" limit for the line (which is different than the sprite number line limit).. when this happens the top most sprite drops out! So it breaks the illusion.. and makes it less capable overall for this kind of approach. It's doable on the SNES, but you have to be much more careful and can't abuse it for more advance stuff with this like I previously mentioned (large enemies or extra columns of parallax objects). Anyway, on the PCE if I clipped the screen down to 224 (which is still more horizontal screen realstate than Ys haha), I could have 1 extra sprite that could appear on top of everything.. so like snow drifts, or light rain, etc.

 

 With MD, as long as you have a clipped width that is 8px less than the sprite line limit, then you're good to go. A few ways to do it, but I guess using the window layer to clip one side would be easiest?

 

 

 

[smds]

50 minutes ago, turboxray said:

The VDC chip has three base resolutions. By that, I mean the video chip is literally clocked at three different speeds.

So kinda the same as MD, which upclocks the VDP to achieve 320px/80 sprites etc...

 

58 minutes ago, turboxray said:

So the video chip is fast enough to fetch more sprite cells at faster speeds relative to the chip mhz (dot clock) - but internally Hudson left the sprite line buffer at 256px. So it's ALWAYS 256px regardless of the "dot clock" pixel resolution.

😑... why did all these companies skimp on a few bytes of memory in the 80's (looking at you sega, I still haven't forgiven you for the CRAM!), well maybe there's more to it than just memory for the linebuffer ?

 

52 minutes ago, turboxray said:

I have the main blocks (don't have to be literal square blocks) always appear in front of the sprites (main character and enemies). This way, foreground layers never drop out. If the character or enemy is behind one of these foreground tiles, it'll dropout... but you won't see it because the dropout will be behind the foreground - it's beautiful.. sprite drop out that you can't see.

Yeah that's the beauty of a sane system 😁. On MD (and PCE I guess) it comes for free due to how the sprite rendering pipeline works. That nintendo thought it was a good idea to drop the frontmost (and potentially most visible!) sprites first seems to be a very dumb decision, but again I don't know how it renders sprites, maybe there was no easy way around that...

 

53 minutes ago, turboxray said:

With MD, as long as you have a clipped width that is 8px less than the sprite line limit, then you're good to go. A few ways to do it, but I guess using the window layer to clip one side would be easiest?

If all you need is to clip 8px then you could make use of the "blank leftmost 8px column to BG colour" bit in the VDP (leftover from the SMS VDP), which still works on the MD VDP. You could use the window to clip too, but if a sprite is high priority then it would appear above even a high priority window... (The window on MD is more or less identical to Plane A, except that it cannot scroll etc)

[turboxray]

1 hour ago, smds said:

So kinda the same as MD, which upclocks the VDP to achieve 320px/80 sprites etc...

Yup! The VCE, often claimed as a "2nd 16bit" gpu in the PCE... which is definitely an exaggeration, but it does control the clock speed to the VDC (which is basically PCE's VDP). Three pixel modes was nice, but I wish they had added a mode that was close to square pixels too. 

 

Quote

 😑... why did all these companies skimp on a few bytes of memory in the 80's (looking at you sega, I still haven't forgiven you for the CRAM!), well maybe there's more to it than just memory for the linebuffer ?

That's always a possibility, but from decapping the chip and knowing all the sprite sorting logic is done during active display.. looks like this is the reason. The did go all out and do ALL 64 sprite table entries as full registers inside the VDC itself.. it's not in vram or partially cached like the VDP. That ate up a lot of the chip realstate. The SuperGrafx solves this with brute forcing byte having two VDCs.. and a few new priority modes to help with balancing. I strongly got the feeling that NEC figured on hardware video upgrades because all the signals are right there on the external bus.. including the digital pixel bus. Sega would have KILLED for that when they developed the SegaCD hahah. You could make a simple device to expand the PCE palette to 32k colors or more -a few glue logic and ramdac. I did ask the SHD3pro team to add this feature as a "PCE+" option, and they said that was easily doable (they're basically already doing it).. but then they dropped off the face of the earth. You know,, MD's got the MD+ and SNES's got the MSU+... need a PCE+.

 

Quote

Yeah that's the beauty of a sane system 😁. On MD (and PCE I guess) it comes for free due to how the sprite rendering pipeline works. That nintendo thought it was a good idea to drop the frontmost (and potentially most visible!) sprites first seems to be a very dumb decision, but again I don't know how it renders sprites, maybe there was no easy way around that...

It's definitely odd choice on the snes. Once you know about it, you'll start to see it in games that have sprite drop out. That Turtles in Time hack that tries to put more sprites on screen at once, the main player drops out even though its the top priority sprite, etc. It's definitely weird and odd looking. Definitely not good for brawlers. I think someone might have made a demo on the snes that actually relied on it.

 

Quote

If all you need is to clip 8px then you could make use of the "blank leftmost 8px column to BG colour" bit in the VDP (leftover from the SMS VDP), which still works on the MD VDP. You could use the window to clip too, but if a sprite is high priority then it would appear above even a high priority window... (The window on MD is more or less identical to Plane A, except that it cannot scroll etc)

 What hahaha. WHAT? I know what you're talking about but I would have never thought that was useable in MD VDP mode lmao. Well.. there you go haha. That's perfect~!

[Kirk_Johnston]

So, in my other topic I mentioned the idea of having a longer amount of development time and how much things can be improved if you just have the time to keep working things out, figuring out how to save memory here, tweaking something there, come up with creative solutions to what might first seem to be insurmountable technical limitations and obstacles at a glance, thinking a little outside the box, even simply making the visuals look prettier with each pass at an artistic level, and just improving on things constantly. And on that note:

 

 

I thought it would be cool to add a bit of a shadow effect like you see in Super Mario Maker, which I think also works here to sell the idea that this could be set in a kind of toy world or staged a bit like in Super Mario Bros. 3 (I guess some of the sprites and tile elements from that game could also be used in other levels here too, now that I think about it). 

 

If you're curious as to how it would be done to work within SNES' limitations, give me a shout about coding it up and I'll happily share the details and produce all the modified assets for you, as I did with some of the previous examples that some nice SNES programmers coded up for me.

 

I don't think I'll do much more on this particular platformer idea as it's not actually a real game, and I'm really just messing around with ideas and what's possible here. But, if I ever do get around to making stuff directly for SNES, I'm sure I'd try a few things like this just for the fun of it and so everyone could see them working on the real deal, much like I've now mocked up around 8 different SNES concepts in GameMaker 8.1 and had a couple tested with actual SNES code to make sure the stuff I'm proposing is feasible. I'll say this though, if a decent "SNESmaker" tool ever comes along, I think I'd just switch everything I'm mocking up in GameMaker 8.1 currently to that tool instead, and God knows what I'd be doing with that. And I think many other budding SNES developers would love a tool like that also. So, fingers crossed something like that comes along in the not too distant future. . . .

Edited August 27, 2023 by Kirk_Johnston

[Tanooki]

@turboxray I'm glad you're here, I want to say that, not as an ass kiss, but because you really know your shit about the PCE in particular but also the others.  I've had over time (no longer, just a PCE Mini) a US and JP duo, a core grafx 1 and 2 too and easily around 100 games of the library between the two and while I have a passing 'get it moment' of what the system can do I am no software engineer and I failed (well D'd) at a coder in college so that ended that dream.  That said, I used to pursue game design for fun, dabbled in tiled background and sprite for fun too, and under an older psuedonym online I used to do the whole NES header hacking, pasofami hacking, translation hexediting of stuff among others in decades past, along with assisted in test/ideas/hardware compares with a few emulator/authors too.  I would NEVER, never speak or behave like Kirk/Incestinal ever does toward people here, and especially coders who know their shit about it, let alone double down and do the 5yo equal of NANANANA with fingers in the ears and eyes crushed closed.

 

The way you're clearly ahead of the curve from my impression as you said you devised some programs to do X Y and Z for various old hardware is clear that Cap'n Quirk here refuses to listen because well you're too right, and that makes you a liability to his self constructed madness.  I am not as up as I was in the 90s and 00s, but even than I used to kind of beta test a bit for Magic Engine as I could compare my Duo.  I understood what the sprite capabilities, were, general speeds of the parts, ram totals, storage capacities on things, the additional memory(etc) of the growing cards into arcade card and so on.  It was fun seeing things explored, grown, understood, and implemented and in my tiny way helping as I could with largely product comparative testing.  Little known fact, semi-but not related, Yang Fanwen was my friend back in the 90s, I was the tester for FWNES, for those unaware, he invented the Famicom Disk System emulation core and file format, and wow that was a trip.   So point is when I speak I don't try and put a bullseye on my face someone with a bad case of Shatneritits, but, I also won't overstep if it's too into the weeds for me at this rate either.  I'd rather find something new or relearn something than act like a tool.  It's why I do appreciate these posts, I also did with HIS posts too for a time, until I started to see things I remembered did not quite add up, then put it together he was this other persona and that's when the gloves slowly came off as I detest liars and that level of deceit.

[Austin]

2 hours ago, Kirk_Johnston said:

So, in my other topic I mentioned the idea of having a longer amount of development time and how much things can be improved if you just have the time to keep working things out, figuring out how to save memory here, tweaking something there, come up with creative solutions to what might first seem to be insurmountable technical limitations and obstacles at a glance, thinking a little outside the box, even simply making the visuals look prettier with each pass at an artistic level, and just improving on things constantly. And on that note:

 

 

I thought it would be cool to add a bit of a shadow effect like you see in Super Mario Maker, which I think also works here to sell the idea that this could be set in a kind of toy world or staged a bit like in Super Mario Bros. 3 (I guess some of the sprites and tile elements from that game could also be used in other levels here too, now that I think about it). 

 

If you're curious as to how it would be done to work within SNES' limitations, give me a shout about coding it up and I'll happily share the details and produce all the modified assets for you, as I did with some of the previous examples that some nice SNES programmers coded up for me.

 

I don't think I'll do much more on this particular platformer idea as it's not actually a real game, and I'm really just messing around with ideas and what's possible here. But, if I ever do get around to making stuff directly for SNES, I'm sure I'd try a few things like this just for the fun of it and so everyone could see them working on the real deal, much like I've now mocked up around 8 different SNES concepts in GameMaker 8.1 and had a couple tested with actual SNES code to make sure the stuff I'm proposing is feasible. I'll say this though, if a decent "SNESmaker" tool ever comes along, I think I'd just switch everything I'm mocking up in GameMaker 8.1 currently to that tool instead, and God knows what I'd be doing with that. And I think many other budding SNES developers would love a tool like that also. So, fingers crossed something like that comes along in the not too distant future. . . .

I think you are talking to yourself, dude.

[OldSchoolRetroGamer]

2 hours ago, Austin said:

I think you are talking to yourself, dude.

He's his own best audience clearly................

 

 

[turboxray]

3 hours ago, Tanooki said:

@turboxray I'm glad you're here, I want to say that, not as an ass kiss, but because you really know your shit about the PCE in particular but also the others.  I've had over time (no longer, just a PCE Mini) a US and JP duo, a core grafx 1 and 2 too and easily around 100 games of the library between the two and while I have a passing 'get it moment' of what the system can do I am no software engineer and I failed (well D'd) at a coder in college so that ended that dream.  That said, I used to pursue game design for fun, dabbled in tiled background and sprite for fun too, and under an older psuedonym online I used to do the whole NES header hacking, pasofami hacking, translation hexediting of stuff among others in decades past, along with assisted in test/ideas/hardware compares with a few emulator/authors too.  I would NEVER, never speak or behave like Kirk/Incestinal ever does toward people here, and especially coders who know their shit about it, let alone double down and do the 5yo equal of NANANANA with fingers in the ears and eyes crushed closed.

 

The way you're clearly ahead of the curve from my impression as you said you devised some programs to do X Y and Z for various old hardware is clear that Cap'n Quirk here refuses to listen because well you're too right, and that makes you a liability to his self constructed madness.  I am not as up as I was in the 90s and 00s, but even than I used to kind of beta test a bit for Magic Engine as I could compare my Duo.  I understood what the sprite capabilities, were, general speeds of the parts, ram totals, storage capacities on things, the additional memory(etc) of the growing cards into arcade card and so on.  It was fun seeing things explored, grown, understood, and implemented and in my tiny way helping as I could with largely product comparative testing.  Little known fact, semi-but not related, Yang Fanwen was my friend back in the 90s, I was the tester for FWNES, for those unaware, he invented the Famicom Disk System emulation core and file format, and wow that was a trip.   So point is when I speak I don't try and put a bullseye on my face someone with a bad case of Shatneritits, but, I also won't overstep if it's too into the weeds for me at this rate either.  I'd rather find something new or relearn something than act like a tool.  It's why I do appreciate these posts, I also did with HIS posts too for a time, until I started to see things I remembered did not quite add up, then put it together he was this other persona and that's when the gloves slowly came off as I detest liars and that level of deceit.

 

 Wow.. pasofami.. that brings back memories. I got into the emulation scene back in probably summer 1996 or so... it was exciting times! And by that, I just mean playing them. It was like every other day new updates were coming out! It was exciting discovering new games via roms you never know about haha. I hadn't done much coding back then. It wasn't until 1999 that I picked up deving assembly Gameboy and Gameboy color (that was my first "console" I coded for homebrew). Watching PS/Saturn cores and now the new N64 development process over the past two weeks for MisTer kinda gave me the same vibes as those early days tho. 

 

 

 I also, for the record, don't believe you have to code to actually understand hardware specs and how to use them. If it comes to effects that heavily rely on the CPU, then sure. But none of the SNES stuff here really involves that. But I do find that as an exception for most people. As in, simply most people don't care to be obsessed enough with old consoles at this deep of a level haha. And a lot of homebrew devs.. usually just want to make a game.. not necessarily 1-up on Rare. And I'm not a badass or anything (plenty of retro devs are my peers). And there ARE people I definitely look up to. I usually don't feel comfortable speaking on stuff unless I feel I have a very solid grasp and/or experience with it. I know his background. I've spent the last year seeing his "growth" by him asking the same question over and over again.. not fully understanding it. I watched him ask information of snes compared to MD from the community, and then immediately weaponizing that information (that he doesn't really understand) on YT comments and Twitter replies - harassing fans and devs... which he is every where anything retro dev related. Rather than taking the time to learn and understand, he wanted these shortcut answers. And got upset with "experts" for not giving him "simple answers". Maybe he's finally out grown that phase, but so weird to see a grown man whine about something like that - and having multiple mental breakdowns over it (got him temp banned). LMAO he kept saying "you get me?". Yeah, I get you alright.

 

 So yeah, while I don't think it's a requirement.. but knowing he does not know the smaller required details for pushing stuff like this (which aren't simple effects), his mock ups don't hold much value. Coupled with the fact that he has no problem misrepresenting the snes as more capable that it is.. because it benefits his agenda (and will argue against it when corrected).. is another reason why I'd what to see it running on the real hardware because he literally has no credit to his name. 

 

 

Quote

I also did with HIS posts too for a time, until I started to see things I remembered did not quite add up

 

 There's nothing wrong with concept exploring. Nothing wrong with wanting to inspire new ways of looking at things too. And there's definitely nothing wrong with using mockups to explore before getting into the real details. I mean it's kinda what devs do when pushing a system. But I not comfortable when people take what we know nowadays, and the tools we have nowadays, the crazy amount of rom we have nowadays, and no schedule like original devs had.. and pretend like this should have been done back in the day and devs are just dumb or whatever for not doing it or realizing it. He's got a bit of that arrogance about him (he's a visionary), besides trying to passing mockup stuff off as legit as if it was running on the real console. It's like bad sandwich of arrogance, ignorance, and irony.

 

 

 I don't get this whole console war thing, in 2023. I understand of a lil bit of fun snarky remarks back and forth between console fans. But this is some sort of mental regression obsession with the console wars of his childhood. I dunno. Maybe this dude had a mental break down back in 2010. Maybe he got into an accident and has brain damage (no, seriously... someone pointed out his publicly posted resume, kinda hints that something happened back in 2010). All I know is, everywhere he goes.. he eventually ends up alienating pretty much every one (who he's requesting help from). I mean, statistically speaking - there's bound to be a few people that feel sympathy for him. I originally did. But after being attacked multiple times on my channel, and in other places -  and seeing him melt down over not getting simple answers or just straight not understanding facts... I don't. I probably shouldn't have called him an idiot and moron on here.. but he rather exhibit that behavior instead of an honest discussion to learn, grow, etc. Maybe it'll piss him off enough, that it motivates him to learn asm haha. I know some people will have sympathy for him, and I'm not going to fault anyone for that. Everyone has their level of tolerance. Apparently I found mine.. twice over. SNES dev scene isn't as big as the MD scene, so maybe they have more tolerance for people coming in like this. But if nothing else, dude has fortitude.

 

 

 I've wasted too much energy on this. Forgive the wall of text. I need to get back to dev stuffs. But yeah, I do feel like there's been a pickup in snes dev energy in the past year or so. 

 

[+Gemintronic]

One good thing about this topic is the mention of tiledpalettequant.  Was able to find the source and use it on my intranet.

https://github.com/rilden

 

Now, if I could just find a tool that does a good job of making assets conform to my oddball 15 color + transparency palette choices.

[Kirk_Johnston]

3 hours ago, Gemintronic said:

One good thing about this topic is the mention of tiledpalettequant.  Was able to find the source and use it on my intranet.

https://github.com/rilden

 

Now, if I could just find a tool that does a good job of making assets conform to my oddball 15 color + transparency palette choices.

Yeah, having that Tiled Palette Quantization tool from Rilden has proven extremely useful and time saving, as I was having to do all this manually and by eye before, which I did for the entirety of my Mode 0 shmup levels and assets for example, although SnesGFX was somewhat useful there for me in terms of just counting colours and making sure I wasn't going above the unique tile limits per BG layer. And prior to Rilden's tool, with the 8bpp 256-colour images specifically, I was just converting any source images into 256 colours in Photoshop 7--yes, the ancient version--and then posterizing to 32 levels to get a close approximation of SNES colours. I know there's other programs that can already do much of this and often better than Photoshop in principle, but I don't like learning new programs typically, especially the less mainstream or the community-made ones, as they're often too convoluted and really not very user friendly imo, so Rilden's tool has been a Godsend for me with how quick and simple it is. Using that along with GameMaker 8.1 for creating my mockups has been great. You can see I've been able to do quite a few different concept tests around taking advantage of the SNES' various colour options alone mostly because of that tool. So it just shows how much a good tool can change everything. GameMaker [before Studio] was/is one of the few game creation tools I've ever used that really was/is just brilliant for beginners to pick up and learn, but also deep enough to get right into coding too when you're ready for that. Although, sadly, it's not a proper SNES development tool, so the best you can do there is use it as an approximation for high quality proof of concepts of what could be done on SNES. And I can only imagine how much a genuinely decent and matured SNES SDK or a proper SNES game creation tool along the lines of "SNESmaker" or GameMaker 8.1 would change everything for a whole lot of budding SNES game creators in waiting who maybe aren't so interested in becoming hardcore Assembly programmers.

Edited August 28, 2023 by Kirk_Johnston

[Kirk_Johnston]

3 hours ago, Kirk_Johnston said:

Yeah, having that Tiled Palette Quantization tool from Rilden has proven extremely useful and time saving, as I was having to do all this manually and by eye before, which I did for the entirety of my Mode 0 shmup levels and assets for example, although SnesGFX was somewhat useful there for me in terms of just counting colours and making sure I wasn't going above the unique tile limits per BG layer. And prior to Rilden's tool, with the 8bpp 256-colour images specifically, I was just converting any source images into 256 colours in Photoshop 7--yes, the ancient version--and then posterizing to 32 levels to get a close approximation of SNES colours. I know there's other programs that can already do much of this and often better than Photoshop in principle, but I don't like learning new programs typically, especially the less mainstream or the community-made ones, as they're often too convoluted and really not very user friendly imo, so Rilden's tool has been a Godsend for me with how quick and simple it is. Using that along with GameMaker 8.1 for creating my mockups has been great. You can see I've been able to do quite a few different concept tests around taking advantage of the SNES' various colour options alone mostly because of that tool. So it just shows how much a good tool can change everything. GameMaker [before Studio] was/is one of the few game creation tools I've ever used that really was/is just brilliant for beginners to pick up and learn, but also deep enough to get right into coding too when you're ready for that. Although, sadly, it's not a proper SNES development tool, so the best you can do there is use it as an approximation for high quality proof of concepts of what could be done on SNES. And I can only imagine how much a genuinely decent and matured SNES SDK or a proper SNES game creation tool along the lines of "SNESmaker" or GameMaker 8.1 would change everything for a whole lot of budding SNES game creators in waiting who maybe aren't so interested in becoming hardcore Assembly programmers.

And, to be clear, when I say "approximation", I mean that in the sense that they're not actual SNES code, so they can only ever really be approximations when they're within the limits of GameMaker 8.1 (GM8.1).

 

But, I've made sure to stick to every SNES spec capability and limitation I'm aware of, hence why my Mode 0 shmup worked basically identically to the concepted version I created and coded in GM8.1, with no real changes to the original design required, despite having four fully overlapping background layers, lots of row/line scrolling, working within the 2bpp colours per tile and colours per layer limits, sticking within the max tiles per layer limits, putting the backdrop colour plus DHMA to good use, sticking to the max sprites on-screen and max sprites per scanline limits (it's not even close in my current versions), making sure my sprite tiles don't go beyond the dedicated VRAM space for them, using a couple of sprites in places to fake a minimal amount of the parallax, timing all the parallax motion to look correct, thinking about how the colour math is going to be used for shadows, thinking about how much is going on at once on-screen and during vblank and hblank with HDMA and so on so as not to push the CPU beyond its limits and cause the dreaded slowdown, etc. Hence why I've held back for now on demoing virtually all the proper gameplay stuff in my mockups, all the enemies and bullets and interactive level elements and such, as I know fine well that's where all the main code and indeed properly optimized code comes into play.

 

In fact, my GM8.1 Mode 0 mockups often actually had/have to be held back a little as I have no clue how to do full line-scrolling there (and any examples that look like that had to be faked using tens of layers to simulate using HDMA to change the speed of multiple sections of a background each frame). If I knew how to do that in GM8.1 I would have had a nice wavy reflection effect on the water in even my demo too. The rotating planet in my space level required me creating I think 120 frames of it moving a pixel or so at a time in Photoshop just to look like it was moving within a window/shape mask, because I didn't know how to create a proper window/shape mask in GM8.1, but I know it's fully possible to use two of them on SNES and indeed update the shape as the screen is being drawn using HDMA. There too I would have even had the shadow rotating across the planet if I could do that in GM8.1, which would have sold the effect even more, but I know it's technically possible on SNES just by changing the shape of the mask using HDMA every scanline and each frame (although, that would have to be tested in real SNES code to see if it would have a detrimental impact to the frame rate with everything else I have planned for that level, which is partly why I never bothered to fake it in my demo for now).

 

And I even learned a couple of other useful things/tricks along the way there, such as how you can fake extra layers using the main/sub screens if absolutely necessary for example, which is something we had to do initially with my bridge level to get it to work based on my original BG layouts, before figuring out a simpler way to achieve the same result without having to abuse the main/sub screens at all--that goes to the idea of simply having more development time I mentioned. Or how the colour math on SNES works a little differently to how it can be portrayed in GM8.1, but you can still convey how it would be done in GM8.1 accurately enough for most people to get the gist of it. I even learned that most SNES developers totally ignore what can be done with overlapping semi-transparency on SNES because they think certain things are "incorrect" from a programmer perspective, without understanding the end result is what matters, and in this case you can in fact have multiple semi-transparent objects/elements cross over each other and look just fine, so long as you think of it as what you see in the end product and not what some documentation or lines of script in some code editor tell you.

 

So, yeah, approximations, but as technically accurate as they can be and as system accurate as GM8.1 can portray. I try to make sure all my demos stick to that rule. Not that I don't make silly mistakes when putting everything together in GM8.1 once in a while--remember that time I accidently used the non-converted main background image rather than the converted 8bpp 256-colour one--but literally nothing that actually breaks the point of the demos/concepts.

 

And, for any of my concept examples, if anyone would like to work with me to get them coded up and running on SNES directly [or on emulators at least], just so everyone can try them out firsthand beyond watching some YouTube videos or playing some GM8.1 executable, I'd be happy to work with them and create working SNES versions there. But, the real goal is to make some actual SNES games eventually--that's when a SNES programmer on indeed me learning to code for SNES directly will be truly essential. Until then, I'm learning new stuff as I go, testing some ideas along the way, sharing some of my SNES concepts, and generally posting some SNES thoughts and various articles and such in places like this, because I enjoy talking about and celebrating the SNES.

 

Now, if you--that's the royal "you"--wanna work on an actual real SNES game with me, that's a whole other ball game. And if you don't, I'm not gonna force you. I'm just posting some SNES-specific stuff in the SNES-specific sub-forum of some site.

Edited August 28, 2023 by Kirk_Johnston

[Tanooki]

@turboxray Yes I was into it that far back.  Around the time I had been self teaching myself both Japanese symbols, using a dictionary, kana chart, and also a hexeditor too.  I would usually translate the Japanese emulator for people into English along with a few other random things (I still have the others, they're old Windows 9x screen buddies.)  You and I both got started about the same exact time then it seems.  Back then I did that and then rolled into decoding and figuring out how to load not just the standard iNES header format but the extended set of bytes too.  Along with a buddy in the NE who had an early dumping kit in raw files, we appended the things, I created headers, and well let's just say between us a couple hundred or so NES (US) titles got online.  About that time I got into working with FanWen and did the testing and execution of the FDS format for emulation and released the files online FanWen made.

 

You get it, I get it, you said as much with "I also, for the record, don't believe you have to code to actually understand hardware specs and how to use them." and that's where HE fails to get as far and that's the problem leading into the hysterics, whining, mental breakdowns and ignoring people including page staff here (and I bet elsewhere.)  And that is the issue, see he just doesn't want to stay within reality when exploring.  It's set hardware, without making some massive upgrade chip/pass through cart of sorts basically slaving the system, what he wants is pure fantasy.  It would be better off just making another so called 'retro indie game' in homage to the 16bit era and doing what you want, not making a system that can't do what you want do it anyway with tinkerbell's fairy dust.

 

Like you said, time wasted, and you're right, there is an uptick, in spite, despite of his antics.  The time has come to crack the egg, maybe it is a bit of console wars level stuff people not liking the Sega underdog getting more of the love, but it is what it is.  SNES is a customized 16bit take on the NES chip which means it's more of a custom outlier and harder to handle.  The Genesis/MD though is a very watered down and gimped version of the very overly popular/used arcade type chips of the 80s to keep it in budget (hence the compromised color detail, color levels, usually crappier audio, etc.)  It's a huge known many used and easy to approach.  It's not about being loved more or less, it's about the path of less resistance.

 

 

 

...and now he has devolved into quoting and talking to himself.  Or is this a case of multiple personality disorder, bipolar, narcissist talking about/to themselves in the third person?

Edited August 28, 2023 by Tanooki

[smds]

17 hours ago, turboxray said:

I strongly got the feeling that NEC figured on hardware video upgrades because all the signals are right there on the external bus.. including the digital pixel bus. Sega would have KILLED for that when they developed the SegaCD hahah. You could make a simple device to expand the PCE palette to 32k colors or more -a few glue logic and ramdac.

The best bit is that the MD VDP can use external CRAM... But the pixel bus pins on the VDP is not connected to anything 😩 🤬

 

17 hours ago, turboxray said:

 What hahaha. WHAT? I know what you're talking about but I would have never thought that was useable in MD VDP mode lmao. Well.. there you go haha. That's perfect~!

Was thinking that maybe I'm confused and it only works in mode 4... So I wrote up a quick test program, and yes it does work in mode 5 as well (tested on real hardware).

Having this functionality is great for games such as shining force 1 and 2, which use H32 (256px) resolution in combination with using a 32x32 tilemap. Except... the shining force games doesn't use it, it uses sprites to hide the scroll seam instead 🤔

Edited August 28, 2023 by smds
addendum