SUB HUNTER on C64, now ported to CPC... When A8 version?

[Tezz]

(Tezz just saw you here: remember the work you started at the Ghost and Pac-Man, do you remember that the 'Eat points were Yellow PF3? And that I was a little worried because it could turn into clash (PF2 was on the Walls...)?

I'll dig out the old planning notes tonight and send you a pm José

[José Pereira]

Jose, can you please post the G2F file? I want to have a closer look as since the Pacmania Tests I am still not 100% familiar with the Prio#0 stuff.

 

-> Bitmap Mode 4colours.

-> DLIs.

-> PRIOR0

 

-> Colours:

PF0- (pair nº colour, luminances 2or10)

PF1- White (0,14)

PF2- Dark Gray (0,4)

Backgr.- any colour, any luminance

 

-> PMs and PRIOR0:

PM0- The shooot or 'guys to rescue':

PM0 colour ( 15,8 ) 'ORING' get PF0->(15,10)/PF1->(15,14)

 

PM1- Our Sub:

PM1 colour ( 14,8 ) 'ORING' get PF0->(14,10)/PF1->(14,14)

 

PM2 & PM3: Enemys can have many colours and luminances 'by Oring' because PF2-(0,4), you can have any PM2&PM3 colour with Luminances 0,2,8,10.

 

 

STATUS AREAS: 1Charset in ANTIC4 40bytes wide Mode (no need any PMs. overlays or underlays here).

Edited September 2, 2011 by José Pereira

[José Pereira]

Me again...

 

Was just answering Sack at Format War regarding Sub-Hunter could run or not at 50fps.

Don't need to write it all here again, soo please enter here and say if my Arithmetics are or not true, but also about this ruinning at 50fps.:

Sub-Hunter 50fps and cycles using

 

 

 

Thanks.

José Pereira.

[Faicuai]

Lots of shapes just to show the 'PRIOR0' to get any colours/almost all luminances possible on Enemys:

 

 

F-SICK (!)

 

Like the "warmer" look of the ocean's floor (more red on it), the overall Luminance-level chosen and the Sprites' color. MUCH better-looking than the C-64 version.

 

 

Bring it on!

 

F.

[José Pereira]

Lots of shapes just to show the 'PRIOR0' to get any colours/almost all luminances possible on Enemys:

 

 

F-SICK (!)

 

Like the "warmer" look of the ocean's floor (more red on it), the overall Luminance-level chosen and the Sprites' color. MUCH better-looking than the C-64 version.

 

 

Bring it on!

 

F.

 

 

Just to get the differences:

-> A8 and C64:

 

-> Now C64 and A8 different screens Grounds Gfxs. (there's always 5colours/luminances of each Stage):

 

 

 

 

 

 

 

 

 

 

Edited September 2, 2011 by José Pereira

[José Pereira]

A8 and C64:

 

One more screen gfxs. type that have 5colour/luminances different, as usual:

 

 

 

 

 

 

For this type of stages there's one more type:

 

And then this ones:

This weekend I'll have all the screens Masters with colours/luminances and Tiles/Charsets.

Then it's time for the Sprites ...

 

 

José Pereira.

[José Pereira]

Wasn't really happy with this last one liminances.

This Ground stages have 3Parallax scrolling that like this would 'scroll looking' better:

Better now, I think...

Edited September 3, 2011 by José Pereira

[José Pereira]

This type of 'Ground gfxs' levels finhished:

Edited September 4, 2011 by José Pereira

[Faicuai]

 

 

 

 

 

 

...Not sure about the games' entire range of screens, but this last pair looks simply excellent. NICE job!

 

The mix of colors, saturation and luma "gradient" (if we could use this term) looks pro-grade. The sprites are easy to see, and blend relatively well wih the environment.

 

F.

[José Pereira]

 

 

 

 

 

 

...Not sure about the games' entire range of screens, but this last pair looks simply excellent. NICE job!

 

The mix of colors, saturation and luma "gradient" (if we could use this term) looks pro-grade. The sprites are easy to see, and blend relatively well wih the environment.

 

F.

 

 

Say that to the coders... I even get back to School to do some Arithmetics...

Sprites can go over that Gfxs. and there are cycles for that... something that I've learn about 6502 cyles Arithmetics...

[José Pereira]

This and others to come are just to some people that don't realize the true...

That's just simply 4colours and DLIs.

That just think that A8 just get this and 4PMs.

 

If that's it then CPCs. just don't get anything... because they just don' have Hardware sprites.

 

PMs. are to be used, but on A8, please, please, put that PMs. above soft sprites

Our Pallete and more cycles would do what's left...

Edited September 4, 2011 by José Pereira

[José Pereira]

This and others to come are just to some people that don't realize the true...

That is just simply 4colours and DLIs.

Think that A8 are getting get this with just four colours each scanlines and DLIs.

 

If that's a problem, then CPCs. just don't get anything... because they just don't have Hardware sprites.

 

PMs. are to be used, but on A8, please, please, put that PMs. above soft sprites

Our Pallete and more cycles would do what's left...

[José Pereira]

I am just doing what some others done.

sadly not many had done it

[+Stephen]

Looks awesome José.

[sack-c0s]

my concern is that it's not just how many cycles - that assumes you can do whatever you want at any point during the screen refresh and it'll work out fine. If you're dumping stuff into a double-buffered bitmap then that's a good enough way of looking at it.

 

when you start racing the bean and adjusting things on the fly it's also a matter of *where* the cycles are available too. That's the bit I was a little bit unsure of.

 

but as I say - if what is in that screenshot can be animated and turned into a game then that's a pretty great piece of work.

[José Pereira]

Time to go into those Darkest stages where lots of Sharks 'flying around':

And lots of Sharks means that some clever way to get the Large Sharks and also the Normal ones where only the two Normal wide ones can use PMs .

The idea of this stages it's to seem darker than the previous ones, only Ground(s) change, as there are always 5stages->5colours/luminances... This 'redish' it's just one of them.

Edited September 6, 2011 by José Pereira

[R4ngerM4n]

Jose, can you please post the G2F file? I want to have a closer look as since the Pacmania Tests I am still not 100% familiar with the Prio#0 stuff.

 

Offtopic: Heaven, your mailbox is full (no pm possible).

[Heaven/TQA]

A8? well... simply try karolj _ nadj @ web.de

[Heaven/TQA]

and Atariage messenger should be possible, too... damned 500 limit... ;=)

[José Pereira]

my concern is that it's not just how many cycles - that assumes you can do whatever you want at any point during the screen refresh and it'll work out fine. If you're dumping stuff into a double-buffered bitmap then that's a good enough way of looking at it.

 

when you start racing the bean and adjusting things on the fly it's also a matter of *where* the cycles are available too. That's the bit I was a little bit unsure of.

 

but as I say - if what is in that screenshot can be animated and turned into a game then that's a pretty great piece of work.

 

Please 'don't concern yourself'...

Something that even if I am not acoder I maybee soneohne(s) behind...

 

This is just as clean as a 'SKIP' or an 'ARIEL' clean of clothes

There isn't any 'abuse' of DLIs., just a single one, just one DLI per scanline but clever that in all screen height there are only 14or15DLIs. most of them in Background colour Registers... and in un-used Blank scan-Lines

 

What you see here it's cllever (or stupid... ) 4colours Bitmap on ecah scanline...

And this is saying that almost the cycles are free for the Soft Sprites.

 

This seems, looks so good but there's nothing special, even not so many DLIs. as you may think of:

Edited September 6, 2011 by José Pereira

[José Pereira]

Your problem, or at least most of you, think I just 'use and abuse' of G2F, just because you still think that I am doing Mock-ups...

 

That's the problem

Edited September 6, 2011 by José Pereira

[simonl]

I think what sack's getting at is that if you are drawing the foreground graphics outside vertical blank then you may get tearing on them if the current raster line falls within a graphic. Say if one of the fish is moving horizontally and the current raster line is halfway through its vertical range, you would get bottom half of the graphic offset slightly, and possibly from a different frame of the animation. The options to work around this are:

 

• draw all the graphics in vertical blank (probably a non-starter given the amount that needs to be drawn)
  
• double buffer the screen so you're always drawing to an offscreen buffer, which obviously uses twice as much memory for the game area - 130XE banking is ideal for this but obviously not compatible with 64k machines or some other RAM upgrades
  
• drawing the softsprites in vertical order and using vcount to delay modification if the beam is in the region you're drawing to
  
• not giving a crap about it and just doing it as fast as possible
  

 

All of these approaches have their merits (including the last one )

 

Cheers,

 

Simon

[emkay]

• draw all the graphics in vertical blank (probably a non-starter given the amount that needs to be drawn)
• double buffer the screen so you're always drawing to an offscreen buffer, which obviously uses twice as much memory for the game area - 130XE banking is ideal for this but obviously not compatible with 64k machines or some other RAM upgrades
• drawing the softsprites in vertical order and using vcount to delay modification if the beam is in the region you're drawing to
• not giving a crap about it and just doing it as fast as possible

 

 

 

On the A8 it should be no problem to use VCOUNT or a DLI on the wanted position for starting the drawing routine on dedicated rasterlines.

If 50Hz is wanted (and reachable) , the graphics just have to be drawn immediately -after- the screenrange has been handled by the displaying hardware. It's almost like double buffer, without double buffer.

 

I'd still like to see how fast Rescue on Fractalus can be without "Double Buffer" by just drawing the graphics as fast as possible. I'd bet, we would occure tearing, because the graphics were calculated faster than the VBI happens.

 

 

 

But softwaresprites with different scrolling speed ranges, we really should drop off our thoughts....

 

When using parallax scrolling, we always could multiplex the PMg..... Or, doing all in software by using a double scanline mode.

Edited September 7, 2011 by emkay

[sack-c0s]

actually I'd completely forgotten about tearing. I was too focused on timing-dependent register changes.

 

but I'm guessing that's a relatively small game in terms of memory footprint - I'm sure you could spare a second buffer...

[simonl]

But softwaresprites with different scrolling speed ranges, we really should drop off our thoughts....

 

When using parallax scrolling, we always could multiplex the PMg..... Or, doing all in software by using a double scanline mode.

 

I think it's doable, but there'd be a lot of lookup tables and indirect Y addressing or self modifiying code involved. I would suggest having preshifted horizontal sprite data and a set of lookup tables for the scroll range, so for each band of parallax you can convert an x position and the current scroll offset (fine and coarse) to an offset, do a 16 bit pointer addition to add it to the LMS address for the start of the line then write the data. I'd have to actually do it to see whether it could be done in the time required though

 

actually I'd completely forgotten about tearing. I was too focused on timing-dependent register changes.

 

but I'm guessing that's a relatively small game in terms of memory footprint - I'm sure you could spare a second buffer...

 

Ah well, I can carry on putting words into your mouth if it's useful for the discussion though In terms of screen architecture it looks ok to me, I would probably redo the status bits so they're squished a little vertically to give more VBLANK time but apart from resetting HSCROL and a couple of playfield color changes it doesn't look like there's too much going on. If I was writing it I would probably put an LMS on each line for flexibility in laying out the screen RAM but that's just force of habit, I'm not sure it's necessary.

 

José, can you post the sizes in pixels of the repeating bands of background and I can try some calculations to see whether it's easy to fit in 64k with two buffers? They look like they'd be good candidates for RLE for the ones that aren't displayed currently, so they could be uncompressed to the buffers at the start of each stage.

 

Cheers,

 

Simon