PoP Slicer sound, should we update it ?

[Jacques]

@emkay, maybe you could try to optimize Tomahawk?

It's a great 3D flight simulator, but more FPS would be welcome.

 

Sincerely, I don't quite understand that fascination with Atari 3D capabilities, and don't think we need next incarnations of RoF. 

Surely we have very good 8-bit CPU running quicker than C64's, but 1 or 3 FPS more than on C64 don't justify "shining" excitement. While I really love Stunt Car Racer comparison to C64, actually no 8-bit computer is shining or designed to cope well with real (calculated) 3D, it was pure 2D era in creators' minds.

But I love "tricks" like Yoomp or Project M, but it's not real 3D.

 

[emkay]

1 hour ago, Jacques said:

@emkay, maybe you could try to optimize Tomahawk?

It's a great 3D flight simulator, but more FPS would be welcome.

 

Sincerely, I don't quite understand that fascination with Atari 3D capabilities, and don't think we need next incarnations of RoF. 

Surely we have very good 8-bit CPU running quicker than C64's, but 1 or 3 FPS more than on C64 don't justify "shining" excitement. While I really love Stunt Car Racer comparison to C64, actually no 8-bit computer is shining or designed to cope well with real (calculated) 3D, it was pure 2D era in creators' minds.

But I love "tricks" like Yoomp or Project M, but it's not real 3D.

 

I have no interest in a discussion if games were "real 3D" or not. But the definition of 3D is clear.

As soon as three dimensional axis take part in a game, it IS 3D.

And in games there is no "real 3D". The projection is always virtual, not real.

If you are about the calculation, you get closer. A REAL CALCULATED 3D game engine can simulate everything.

A dedicated 3D games offers the 3D playability up to what the machine is capable of.

Not to talk of Starraiders (and the unofficial Starraiders 2 ) which really were 3 dimensional axis calculated space simulations. Starraiders is older than the C64. Keep this in mind.

Edited May 30, 2020 by emkay

[_The Doctor__]

Jacques, what do you consider 3D?  Do we need stereoscopic multi image goggles or glasses?

[Jacques]

No, as for 8 bit I mainly mean 3D vector gfx, since textures are not possible, and I mentioned Tomahawk above. Anyway, I stop off-topic, now. Sorry 😉

[emkay]

If things are about "SNES" , why not doing the full style then?

 

The Prologue should be SNES style as well then...

 

Here a quick proposal .

 

The picture could be 240 pixel high. The range where the text is shown, can be high resolution. Scrolling the text with a wait for every second VBI, allows to use interlace for the text . The scrolling would help to distract from flickering.

This could be done without a use of DLIs and could be shown while loading from disk.   

 

Remember, the image can have up to 9 colors also without any DLI use

 

Edited June 5, 2020 by emkay

[rensoup]

4 hours ago, emkay said:

If things are about "SNES" , why not doing the full style then?

I did consider it... but too much work (scrolling) and too much memory

[emkay]

37 minutes ago, rensoup said:

I did consider it... but too much work (scrolling) and too much memory

Come on. Vertical scrolling is a "self runner" . You can do it in Basic without "much work". 

 

You could set the DL to have a fixed range of scrolling text mode. It's really hard to "inc " the scroll register 7 times and to set the LMS for the next line, every 8 intervals . The graphics need some dedicated memory size, but if 6K is the problem, just release the game without a Prologue

 

For the records: If you do the screens this way, you could load data while the screen is schown. 

Som, even if it needs time to load the data, the level loading will be shortened while reading the text.  

 

[rensoup]

It's easy to scroll if I predraw the text of course but then it takes 2 screens + the picture and they have to be in the main 64KB (where I don't have space for that pic )

 

I have about 16KB for the 216 lines title pic + the prologue font + code in extended mem. and about 2.5KB for code in main mem (+screens+ DL + PMG area which are shared with the game)... I don't even know if that's going to fit yet so a few extra KB on top is a problem.

[+Stephen]

50 minutes ago, rensoup said:

It's easy to scroll if I predraw the text of course but then it takes 2 screens + the picture and they have to be in the main 64KB (where I don't have space for that pic )

 

I have about 16KB for the 216 lines title pic + the prologue font + code in extended mem. and about 2.5KB for code in main mem (+screens+ DL + PMG area which are shared with the game)... I don't even know if that's going to fit yet so a few extra KB on top is a problem.

How do you manage a project of this scale on this machine?  Sorry if it's been asked before, SO much info in this thread.  What are your dev tools, are you using something like GIT for source control?

[emkay]

6 hours ago, rensoup said:

It's easy to scroll if I predraw the text of course but then it takes 2 screens + the picture and they have to be in the main 64KB (where I don't have space for that pic )

 

I have about 16KB for the 216 lines title pic + the prologue font + code in extended mem. and about 2.5KB for code in main mem (+screens+ DL + PMG area which are shared with the game)... I don't even know if that's going to fit yet so a few extra KB on top is a problem.

What about a memory saving solution at all  that also is using "no CPU" for displaying?

You could do a frame for the text using on charset and 4 characters to get big letters. To stretch them a bit you could use an interleaved Mode  (Mode 2, Mode 2, Blank) to have the full 16 pixels height for a character available.  Switching to a second charset, allows to have the interlace.

The image could be build on Mode D.

 

2 fonts 2000 Bytes

12 lines for the char mode (always 2 hidden)  480Bytes + blank lines in the scrolling range.

Mode D 160 lines 3200 Bytes

 

 

 

[rensoup]

17 hours ago, Stephen said:

How do you manage a project of this scale on this machine?  Sorry if it's been asked before, SO much info in this thread.  What are your dev tools, are you using something like GIT for source control?

I kept a diary, well up until some months ago, so I'll probably put that up somewhere...

 

I wouldn't say it's that big a project (I had to work on projects where I felt I was almost drowning constantly) but for dev tools, I don't have anything fancy:

 

-Perforce for source control (free for a single license)

 

-Beebasm because I started from the BBC version (just for convenience) and Kieran, the coder provided all the files needed for building the project on github.

One thing that I like about it is that it's really easy to work with projects that use extended memory (it's platform agnostic). The way this is done is by building the whole project every time, not just modules, so if you have unresolved labels, you'll know straight away.

Drawbacks are that you don't get debug labels in Altirra format(to fix it, I just parse the text output) and you can't produce an Atari binary (I just have a MADS wrapper that incbins the beebasm binary and jump to its start address)

 

-Altirra nice debug environment, most useful feature for hard to track bugs is the debug history window.

 

Paint.net for most graphics tasks, I find it the right middle ground between retro paints (grafx2) and modern ones (PS, gimp) which are a major pain to use.

 

Devstudio for writing C# graphics converters (lots of time is spent on those)

 

That's it I think.

[rensoup]

12 hours ago, emkay said:

2 fonts 2000 Bytes

12 lines for the char mode (always 2 hidden)  480Bytes + blank lines in the scrolling range.

Mode D 160 lines 3200 Bytes

It's a variable width font, you can't use char mode, it has to be modeF

[emkay]

28 minutes ago, rensoup said:

It's a variable width font, you can't use char mode, it has to be modeF

It always takes so long with your answer

 

The thing is that , if you use Mode D in a wide range of the screen, you might get enough cycles to set the graphics on the fly.  Showing a software hires interlace scrolling.  Possibly no 2nd buffer needed. 

 

80 scanlines for the "scrolling" means 3200 Bytes to write to the buffer in a frame. 

And, really, the scrolling would help to distract from any interlace flicker. 

[rensoup]

ModeD for the picture would be butchery... that's a quarter of the original size.

 

I'm going to stick to hires text and we'll see what people think when it's released. 

[emkay]

4 hours ago, rensoup said:

ModeD for the picture would be butchery... that's a quarter of the original size.

 

I'm going to stick to hires text and we'll see what people think when it's released. 

 

Not sure what people expect from the 1979's hardware, but for me Mode D fits very good.

The mockup is cheating a little , but the image is there in the "mode d" resolution.

[emkay]

Mode D for the mains graphics, hires text for the scrolling range, and everything would be a perfect SNES imagination.

[emkay]

That's what a unique loading screen defines.

You have graphics and some FX on the screen at a low cost of "everything", and you could load a lot stuff from disk while it's shown.  

[emkay]

Not to mention the shape of the Persian palace likeness is there

[emkay]

How about the progress ?

[rensoup]

On 7/21/2020 at 11:30 PM, emkay said:

How about the progress ?

No progress... still working on a tool to help with coloring