Wouldn't this make it an intended range of 256K? Anyway, it seems that the TG16, Genesis, and SNES could have originally intended to have 128KB of VRAM.

At 128 bytes per 16x16 tile, 10 bits cover 128K. The remaining bit is intended for the 2-bit mode and is zero otherwise.

Quote:

tepples wrote:

The VDC was designed to use either fast or slow VRAM.

What, were they unsure?

Yes. Hudson was probably unsure of whether RAM makers would be able to provide fast enough RAM, so it designed in both fast and slow modes. Had RAM makers not hit their target by 1986, the PC Engine would have been specced with slow memory, all games would use slow mode, and then years later, there would be hacks to solder in faster RAM and patch games to alleviate slowdown.

Quote:

I was about to say how this could be useful to conserve VRAM space, but I'm guessing 4-color tiles apply to everything, not just a certain sprite or something like that...

Add me to the list of people who use psycopathicteen's hi-oam algorithm.

Espozo wrote:

Really though, making a good vram engine is much, much worse.

I just finished writing, optimising and unit testing my vram engine. It took 3 months of on-again, off-again development but it's finally complete.

Now that the boring part is done my productivity should increase.

Author:

TOUKO [ Mon Feb 01, 2016 1:52 am ]

Post subject:

Re: Why no SNES homebrew scene?

Quote:

I am also confused by this? Why does it have 11 bits if the PCE can't use 8x8 sprites?

Like tepples said, it intended to use 128ko of VRAM ..And those 11bits are not the same for sprite cells size, those are in another word (the fourth),it's 11 bits for sprite patterns addresses in VRAM only.

Yes it's sure, you can use slow/fast VRAM with VDC(it's designed for), and you can also use a 8/16 bits CPU, you can switch all VDC's registers in 16 bits mode instead of 2 8 bits with a connected pin to +VCC .

I think the VDC was not designed specificaly for PCE, but for general uses in multiple systems .Slow VRAM can not be used for PCE's med/hi res,even with his 100ns VRAM, still works under speed specifications for hires (93ns is required),but works .

Author:

MottZilla [ Tue Feb 02, 2016 10:18 pm ]

Post subject:

Re: Why no SNES homebrew scene?

Sik wrote:

MottZilla wrote:

For example I've thought that Sega should have outfitted the Genesis VDP with enough Color RAM for 128 Colors instead of 64 and made the Background and Sprites use different section like the NES or SNES does.

That was their original intention, but they ran out of die space ¯\(º_o)/¯ (instead we got less-used features like S/H that took up less room) There's a good reason why the VDP can use an external color DAC, but again that'd have made the console more expensive (ugh).

If they ran out of die space then I think they should have scrapped the Master System video modes if that would have allowed for 128 colors. It would have been far more useful in the long run.

Author:

tepples [ Mon Jul 24, 2017 6:29 pm ]

Post subject:

Re: Why no SNES homebrew scene?

Fekinox in the FamiTracker Discord server recommended a few sources for waves to convert to BRR:

Some tracker compo organizers make available a sample pack for use in that compo

This leaves filling BG2 and BG3 and testing on all three major variants (1/1/1, 2/1/3, 1CHIP) of each region as the remaining blockers of stepping up from NES to Super NES.

Author:

HihiDanni [ Mon Jul 24, 2017 7:01 pm ]

Post subject:

Re: Why no SNES homebrew scene?

Filling BG2 and/or BG3 seems more like an issue for artists (and depending on the game, might not even need to be very detailed). And then you have the fact that for a lot of cases, you don't need a particularly large BG2 or BG3 either. I imagine you could just make a static tilemap and tileset, send them to VRAM once, then just adjust the BG2/3 scroll registers on VBlank, and it would be good enough. If you wanted something larger you'd need to use tile reloading like BG1, yes, but then, that's what code reuse is for.

Author:

tepples [ Mon Jul 24, 2017 7:07 pm ]

Post subject:

Re: Why no SNES homebrew scene?

HihiDanni wrote:

Filling BG2 and/or BG3 seems more like an issue for artists

Which is my point: more graphics means paying your artist for more hours of work than on 8-bit, or inflating a 1-man hobby project to one where the producer-programmer has to hire an artist in the first place.

Author:

psycopathicteen [ Wed Jul 26, 2017 8:55 am ]

Post subject:

Re: Why no SNES homebrew scene?

UnDisbeliever wrote:

Espozo wrote:

Really though, making a good vram engine is much, much worse.

I just finished writing, optimising and unit testing my vram engine. It took 3 months of on-again, off-again development but it's finally complete.

Now that the boring part is done my productivity should increase.

I just added vertical and horizontal sprite runs to my animation engine, so I can have shorter metasprite data.

Author:

Drew Sebastino [ Thu Jul 27, 2017 11:21 am ]

Post subject:

Re: Why no SNES homebrew scene?

tepples wrote:

HihiDanni wrote:

Filling BG2 and/or BG3 seems more like an issue for artists

Which is my point: more graphics means paying your artist for more hours of work than on 8-bit, or inflating a 1-man hobby project to one where the producer-programmer has to hire an artist in the first place.

Am I an outlier by not so much being interested in making a game, but programming instead? I think a powerful, all purpose engine could get people into making SNES games who don't have a whole lot of programming knowledge to begin with. As they get more experience, they can actually modify the game engine too. I'm envisioning something like SMW hacking except much less shitty.

Unfortunately, I haven't done any programming this whole summer. Now with Splatoon 2 out, I don't see that changing.

psycopathicteen wrote:

I just added vertical and horizontal sprite runs to my animation engine, so I can have shorter metasprite data.

What does this mean?

Author:

tepples [ Thu Jul 27, 2017 11:34 am ]

Post subject:

Re: Why no SNES homebrew scene?

Espozo wrote:

I think a powerful, all purpose engine could get people into making SNES games who don't have a whole lot of programming knowledge to begin with.

I agree, but you still need competent graphic design to make the engine's tech demo attractive to modders.

Espozo wrote:

As they get more experience, they can actually modify the game engine too. I'm envisioning something like SMW hacking except much less shitty.

Essentially all Super Mario World hacks that I'm aware of leave the graphics for at least one block or character untouched. You'd need a total conversion of SMW, wiping all Nintendo graphics from existence, to form the set of graphics that will be used to demonstrate an original engine.

Espozo wrote:

psycopathicteen wrote:

I just added vertical and horizontal sprite runs to my animation engine, so I can have shorter metasprite data.

What does this mean?

If it's anything like the metasprite format in The Curse of Possum Hollow, it means that if a cel is 48 pixels wide, you used to get this for each row of 16x16 pixel sprites in the cel:

Am I an outlier by not so much being interested in making a game, but programming instead?

I enjoy programming much more than other aspects of game design (testing, graphics design).

But, without a goal, a specific finish line, your motivation will go to crap...and you get distracted (Splatoon) and nothing gets done. Make small goals. Not, I will make a game this year. But...I will spend 2 hours programming today. I will draw some pixel art this weekend. Etc.

Author:

Drew Sebastino [ Thu Jul 27, 2017 1:26 pm ]

Post subject:

Re: Why no SNES homebrew scene?

Quote:

Essentially all Super Mario World hacks that I'm aware of leave the graphics for at least one block or character untouched. You'd need a total conversion of SMW, wiping all Nintendo graphics from existence, to form the set of graphics that will be used to demonstrate an original engine.

I doubt I'd use SMW assets.

Quote:

If it's anything like the metasprite format in The Curse of Possum Hollow, it means that if a cel is 48 pixels wide, you used to get this for each row of 16x6 pixel sprites in the cel:

I don't see any advantage to doing this over letting sprites be anywhere in the metasprite, other than space, unless that is the advantage.

Quote:

(Splatoon)

God, I hate myself...

Author:

tepples [ Thu Jul 27, 2017 2:52 pm ]

Post subject:

Re: Why no SNES homebrew scene?

Espozo wrote:

tepples wrote:

You'd need a total conversion of SMW, wiping all Nintendo graphics from existence, to form the set of graphics that will be used to demonstrate an original engine.

I doubt I'd use SMW assets.

I agree. But first we'd need to see the assets you would use. And my point is that a game comparable to those from the Super NES launch window requires a lot more such assets than a game comparable to those from the NES launch window.

Author:

psycopathicteen [ Thu Jul 27, 2017 3:25 pm ]

Post subject:

Re: Why no SNES homebrew scene?

Espozo wrote:

tepples wrote:

HihiDanni wrote:

Filling BG2 and/or BG3 seems more like an issue for artists

Which is my point: more graphics means paying your artist for more hours of work than on 8-bit, or inflating a 1-man hobby project to one where the producer-programmer has to hire an artist in the first place.

Am I an outlier by not so much being interested in making a game, but programming instead? I think a powerful, all purpose engine could get people into making SNES games who don't have a whole lot of programming knowledge to begin with.

The problem is people always look at the source code of these engines (which does all the dirty work for them) and give up when they can't understand 100% of the instructions.

Author:

HihiDanni [ Thu Jul 27, 2017 4:22 pm ]

Post subject:

Re: Why no SNES homebrew scene?

The people who know how to program in some assembly language, and the people who know how to or want to spend time programming a game engine from scratch are not necessarily one and the same group. We spend a lot of time discussing how to make DMA queues, do metasprites, etc. but not really going the extra mile and providing already working implementations of these concepts in a readily usable package. That's the whole point of making an engine.

And if all you do is just dump a bunch of source code somewhere, of course it probably wouldn't generate a ton of interest, especially if it's largely unexplained. Even experienced programmers want documentation. The best way to get people to use something is to show them how, to invite them to do so by explaining how you go about creating screens, adding objects and assets to the game, and tying everything together into a playable game. And example games are good but you also need to provide a clean template for people to use, so that they don't have to pick apart the game-specific stuff to get to the engine itself.

I think proper tools and (documented!) frameworks will go a long way towards generating homebrew interest. The less time spent banging rocks together to make fire, the better.