Are the NEXT's graphics 'authentic?'

[helpcomputer0]

although I do agree with Timmy that they should remain private or have "this is a mockup, does not represent actual game" until you've ran it past a coder to see if it is viable

No one is paying for a mockup so why do I have to keep it secret or get the agreement of anyone else to share it?

If you want to actively discourage people getting involved in the Next community this would be a good way to do it.

[ParadigmShifter]

No I'm just saying make it clear it's a mockup otherwise we get into hype and Sinclair User reviews of Nemesis type stuff

[helpcomputer0]

No I'm just saying make it clear it's a mockup otherwise we get into hype and Sinclair User reviews of Nemesis type stuff

I think I would always make it clear, or have in the past anyway.

I don't know anything about what went on with other games. If it involved people being mislead about a commercial product then that's a different topic.

If I just create a mockup I don't owe anyone anything, even if people get hyped.

[ParadigmShifter]

I was just backing up Timmy's stance a bit while also saying I like mockups and willing to rip them off since I can't draw

Carry on, your graphics are excellent. I also need game ideas and inspiration otherwise I'm going to paint myself into a corner of "ParadigmShifter the puzzle game mister"

[helpcomputer0]

I was just backing up Timmy's stance a bit while also saying I like mockups and willing to rip them off since I can't draw

Carry on, your graphics are excellent. I also need game ideas and inspiration otherwise I'm going to paint myself into a corner of "ParadigmShifter the puzzle game mister"

I don't completely disagree with Timmy, and I don't know the full story of this other game so I won't comment further on the mockup thing.

I just want to see more people getting involved with the Next, and obviously ZX Spectrum in general.

[ParadigmShifter]

Ok let's all agree to not completely disagree I think we generally agree anyway

I have no idea about Timmy's game either to tell the truth

[Timmy]

Ok let's all agree to not completely disagree I think we generally agree anyway

I have no idea about Timmy's game either to tell the truth

I'm pretty sure we generally agree.

I'm not sure what you mean by "my game", but there must be enough stories floating around where the preview pictures in magazines did not match the final product. Of which the most famous one is about how Outrun looked and played much differently than it was suggested in the magazine previews.

There must be a thread on this forum about it, right?

[1024MAK]

… there must be enough stories floating around where the preview pictures in magazines did not match the final product. Of which the most famous one is about how Outrun looked and played much differently than it was suggested in the magazine previews.

There must be a thread on this forum about it, right?

There has since almost the start of commercial computer gaming been advertisements or ‘news articles’ showing artists impressions, mock up game screens or screenshots from other computers that look better than the actual game graphics that you actually get.

I don’t know if there is a topic on these forums, but yes, it’s likely been discussed before on another forum.

Mark

[AndyC]

i'm not that familiar with cpc+ but i suspect that actual pixel source size is not in the dedicated (limited) sprite memory

Each fixed size 16*16 sprite has its pixels stored in 256 memory mapped registers. You can't repoint it at a different image, to change what, say, sprite 1 looks like you have to overwrite those 256 registers.

And yes, that's 1 byte per pixel, even though only 4 bits are used, so you have to write twice as many bytes as you'd expect.

well, because if you think pixels, not bytes, then 16K is not "very generous", it's actually "very much not much"

...even compared to the old original humble Spectrum

It's enough for 128 16*16 frames at 16 colours by my reckoning. That's quite substantial. It's not enough to make everything easy, but then no system ever was. Even the NES could only manage 256 8*8 sprites at any one time.

[Sokurah]

Like, imagine what a Commodore 64 NEXT would be like. 99% compatibility with C64, but options to have processor ramped up to 8 or 12 Mhz or something, 512 KB RAM or more, dual SID or better, a VERA-like chip.

... and even more brown

[HEXdidnt]

Well I can't draw and have no imagination so mockups and game ideas are fine by me, although I do agree with Timmy that they should remain private or have "this is a mockup, does not represent actual game" until you've ran it past a coder to see if it is viable

I tried exactly that, some months ago, with my hypothetical Empire Strikes Back design. I found that most coders are reluctant even to offer advice, recommendations or opinions on viability - even when that's all that's asked for - because of an assumption that someone presenting their "great idea for a game" is eventually going to ask them to work for free.

[AndyC]

I tried exactly that, some months ago, with my hypothetical Empire Strikes Back design. I found that most coders are reluctant even to offer advice, recommendations or opinions on viability - even when that's all that's asked for - because of an assumption that someone presenting their "great idea for a game" is eventually going to ask them to work for free.

Part of the trouble with that is that it's difficult for a coder to judge necessarily. I might think something isn't viable, but it doesn't mean a better coder out there might be able to pull it off. It's also not so easy to judge what the expectation of a graphics artist is from just a mocked up screen.

I've also seen artists start with something like that, get told it's possible, and then roll out a long stream of complex animations for all the sprites that just aren't likely to be feasible. And it's hard to trample on someone's vision when, for all I know, a better coder might pull it off.

[Lethargeek]

Each fixed size 16*16 sprite has its pixels stored in 256 memory mapped registers. You can't repoint it at a different image, to change what, say, sprite 1 looks like you have to overwrite those 256 registers.

And yes, that's 1 byte per pixel, even though only 4 bits are used, so you have to write twice as many bytes as you'd expect.

then it's even worse design than i thought

It's enough for 128 16*16 frames at 16 colours by my reckoning. That's quite substantial.

That's quite insufficient even by early 1980s standards for hw sprite engines. Heck, even the ancient Atari 800 in 1979 was able to use dozens of Kbytes as pixel data for its (otherwise very limited) sprites.

It's enough for 128 16*16 frames at 16 colours by my reckoning. That's quite substantial. It's not enough to make everything easy, but then no system ever was. Even the NES could only manage 256 8*8 sprites at any one time.

NES sprite pixels are stored in the cartridge ROM, thus limited only by the mapper it uses
(well, maybe not so simple, as it probably could use only one ROM page per scanline, but still)

[SaNchez]

with hw sprites (and dynamically generated picture in general) you have to store everything for the worst case, see above

please answer the question: why do you need to store more than 16kb in vram, if 16kb is the maximum that can be shown on the screen in one frame? even if your vram was 1024kb in size, you can only display 16kb at a time.

[SaNchez]

you can't as there's not enough cpu speed (you need more than 8x as the memory isn't as easily adressable, but on the NEXT you have even less iirc)

Please answer one more question: what processor is in the zx spectrum next, what is its clock frequency, how is mmu implemented?

[AndyC]

then it's even worse design than i thought

Sure. But that's what makes it authentic, the limitations of trying to extend an existing design using genuine 90s technology and coming in at a reasonable budget.

That's quite insufficient even by early 1980s standards for hw sprite engines. Heck, even the ancient Atari 800 in 1979 was able to use dozens of Kbytes as pixel data for its (otherwise very limited) sprites.

The Atari 800 had maybe 8 or 16K of RAM in total that had to be shared with everything. It could be expanded to 48K, but sharing all that RAM with sprite hardware there would have also been compromises elsewhere.

Nothing was ever "free" on 8-bit machines (and even 16-bit ones to be honest). I think a lot of Speccy coders got the impression that hardware sprites would make loads of problems go away, that you get all of the CPU power they were used to but also didn't need to spend it drawing to the screen. The reality was you needed a lot of CPU power juggling hardware sprites - whether it was reloading them, multiplexing them or just CPU time sacrificed to let the hardware read memory.

NES sprite pixels are stored in the cartridge ROM, thus limited only by the mapper it uses
(well, maybe not so simple, as it probably could use only one ROM page per scanline, but still)

There were a lot of mappers that help, to some degree, but actually the NES sprites are pretty limited, both in number and storage. And the result was you usually got used to a degree of flickering. That flickering being the result of programmers having to juggle the ordering of sprites because they wouldn't all get drawn if more than a tiny handful were on screen.

Honestly the Next limit of having 16K to store sprite frames and maybe having to reload parts of it on every frame to display what you need still seems pretty good to me. Definitely enough to pull of anything a "normal" Spectrum could do an still have improved visuals.

[catmeows]

Please answer one more question: what processor is in the zx spectrum next, what is its clock frequency, how is mmu implemented?

Well, everyone had different vision of ZX Next. I'm not really happy with it either, because I wished rather AllExistingExtensionsInOne (ATM, Uno) instead of new features. But that's fine, as I said, everyone had different vision.
Where I really see as missed opportunity is Z80N.
Some instructions (MUL; ADD RR, R; ADD RR, N) are welcomed help, but there is no support for compiled languages (no index by stack) and there is no support for larger memory (MMU is really weak substitute for wider address space). Instructions PIXELAD, PIXELDN are complete nonsense, LD*X aren't much better, as they are focused to improve performance in particular video mode (something like [HL]=([HL] and [DE]) or [BC] would be more general). The more useful would to extend group of operations available for 16bit target (16bit OR,AND,XOR, CP).
IDIV, FDIV (like on M68HC16) would be also nice, though probably too much.

[SaNchez]

Personally, I really like the extended commands of the Z80N it’s clear that they are not a mindless copy of other types of cpu, they feel the experience and dreams of many programmers who wrote code for the classic Spectrum. I wrote code for several games on NEXT, and enjoyed using almost all the new commands, even PIXELAD and PIXELDN.

[Lethargeek]

please answer the question: why do you need to store more than 16kb in vram,

please pay attention to what i'm saying here and you will find answers without repeating the same questions again
as already told, because i may need it to make an "extended" version of any possible standard spectrum scene
and it turns out it might need much more than 16K of sprite patterns

if 16kb is the maximum that can be shown on the screen in one frame? even if your vram was 1024kb in size, you can only display 16kb at a time.

so you admit that the Next is less capable than the ancient Spectrum if things are being measured in pixels instead of bytes

Please answer one more question: what processor is in the zx spectrum next, what is its clock frequency, how is mmu implemented?

this is not one but 3 questions and the answers are
1) none, it has a hw emulated custom core
2) up to 28MHz with wait states
3) the way you need to check segments and switch pages for "extended" bitmap gfx

[Lethargeek]

Sure. But that's what makes it authentic, the limitations of trying to extend an existing design using genuine 90s technology and coming in at a reasonable budget.

i'm not sure if you're talking about spectrum or cpc+ now
anyway, it's early 80s tech, not 90s
even a blitter (a much better solution and closer to original spectrum gfx) is mid-80s

The Atari 800 had maybe 8 or 16K of RAM in total that had to be shared with everything. It could be expanded to 48K, but sharing all that RAM with sprite hardware there would have also been compromises elsewhere.

actually all the RAM (all the address space) was shared with the ANTIC from the start

Nothing was ever "free" on 8-bit machines (and even 16-bit ones to be honest). I think a lot of Speccy coders got the impression that hardware sprites would make loads of problems go away, that you get all of the CPU power they were used to but also didn't need to spend it drawing to the screen. The reality was you needed a lot of CPU power juggling hardware sprites - whether it was reloading them, multiplexing them or just CPU time sacrificed to let the hardware read memory.

and not just that, but also live with extra limitations you don't have with software sprites

There were a lot of mappers that help, to some degree, but actually the NES sprites are pretty limited, both in number and storage. And the result was you usually got used to a degree of flickering. That flickering being the result of programmers having to juggle the ordering of sprites because they wouldn't all get drawn if more than a tiny handful were on screen.

this has nothing to do with the pissible number of sprite patterns

Honestly the Next limit of having 16K to store sprite frames and maybe having to reload parts of it on every frame to display what you need still seems pretty good to me. Definitely enough to pull of anything a "normal" Spectrum could do an still have improved visuals.

and i just gave you even a real-world example when it's NOT enough

[Lethargeek]

Instructions PIXELAD, PIXELDN are complete nonsense, LD*X aren't much better, as they are focused to improve performance in particular video mode (something like [HL]=([HL] and [DE]) or [BC] would be more general)

agreed, it's like "fixing" something that ain't broke
improving video access efficiency should be done by modding video hardware, not cpu
why not auto transparent adress mapping useful even with the old standard z80 instructions?

[SaNchez]

please pay attention to what i'm saying here and you will find answers without repeating the same questions again
as already told, because i may need it to make an "extended" version of any possible standard spectrum scene
and it turns out it might need much more than 16K of sprite patterns

You can store many more sprite templates in main RAM, and load them into VRAM as needed. You can't show more than 16kb (32Kpix) of sprites in a single frame at any one time, so there's no point in having more VRAM.

so you admit that the Next is less capable than the ancient Spectrum if things are being measured in pixels instead of bytes

Perhaps the problem is that you don't understand the essence of a SPRITE: it is an animated and/or moving OBJECT that can be implemented in a HW or SW way, and that does NOT mess up the background. (I think you don't understand, because you said earlier that a killed enemy only takes up 2 sprites. It doesn't take up ANY sprite, it's the background).
In the example you gave, you can visually see the sprites are a maximum of 8kpix (even though the whole game area is 32kpix). On NEXT you can output 32Kpix of sprites, which is four times as much.
If you claim there could be more sprites in the example you gave, provide a screenshot, I'd be happy highlight with a pencil out the sprites for you so you understand what are sprites and what are backgrounds.

this is not one but 3 questions and the answers are
1) none, it has a hw emulated custom core
2) up to 28MHz with wait states
3) the way you need to check segments and switch pages for "extended" bitmap gfx

In classic ZX Spectrum CPU also works with wait states, but unlike it Z80N has a convenient memory management and additional commands that accelerate the work with extended graphics, due to which the same or higher speed of work with bitmap is achieved.

To summarise, I can responsibly say that I can replicate the gameplay of ANY classic game using extended graphics, either with HW sprites or directly drawing on Layer2, and the FPS will be the same as in the original, or higher, but definitely not lower.
If YOU can't do it, then don't say it's impossible in principle.

P.S. If anyone is interested in what I wrote in the paragraph above, I'm open to suggestions. Of course, I'm not willing to do it for free, so your part of the contract is to organize the company on kickstarter.

[SaNchez]

3) the way you need to check segments and switch pages for "extended" bitmap gfx

And by the way, if you had studied the issue, you would know that you don't need to switch pages to full access (read and write) ALL 48Kb of bitmap (Layer2).

[AndyC]

i'm not sure if you're talking about spectrum or cpc+ now
anyway, it's early 80s tech, not 90s
even a blitter (a much better solution and closer to original spectrum gfx) is mid-80s

I was referring to the CPC+, which was made in 1990. With 1990's hardware technology. And thus subject to the limitations therein. Sure sprites existed before then but that's not the point. What you could cost-effectively build in the early 90's was different from what the state of the art was. And what you could add to an existing architecture without breaking things like memory timings was equally limited.

actually all the RAM (all the address space) was shared with the ANTIC from the start

Yes, but when there is only 8K of RAM, and it has to store everything, you don't get 48K of sprite frames.

And even if you expand the machine to 48K that's all you get, whereas the ZX Next has 1Mb (at least) that you can store graphics/code in to load into VRAM as required.

But the main point is that this flexibility doesn't come for free in the design. On an A800 you can very easily lose entire scan lines worth of CPU time to the DMA controller. Even the C64, which has a better sprite system, suffers a lot in this regard (even having reduced the CPU speed considerably it has "bad lines") because using the main memory to store sprite frames necessarily impacts performance.

and not just that, but also live with extra limitations you don't have with software sprites

Which was always where the Spectrums strength was. It's why every playground argument with C64 fans would point out games that had bigger sprites on the Speccy or to silly things like the transparent line through the middle of every character in Double Dragon because the programmers hit hardware limitations with multiplexed sprites.

Hardware sprites will always have fixed limitations. They also gain a bunch of benefits, notably not needing the background restored, being easy to position to a specific pixel and not suffering from attribute clashing. The trick is trading these off against each other. Nothing stops you still using software sprites if they solve a specific issue better (even the C64 did that on occasion).

and i just gave you even a real-world example when it's NOT enough

No, you haven't. There are about 6 enemies on screen plus the player, and eyeballing it they look about 24*64 pixels. In 16 colours I make that about 384 bytes each. So that's less than 3K for everything visible. So that's how many frames need to be loaded into video memory at any one time. Anything more is just a benefit in terms of being able to cache extra frames in advance.

[AndyC]

agreed, it's like "fixing" something that ain't broke
improving video access efficiency should be done by modding video hardware, not cpu
why not auto transparent adress mapping useful even with the old standard z80 instructions?

Yeah I was never keen on the idea of changing CPU instructions to suit other hardware. It's one of the things that deviate from the idea Sinclair would have actually built this back in the day - they certainly weren't in a position to have a custom Z80 design with Spectrum specific instructions.