Mode 15 PAL Blending?

[José Pereira]

@JAC!

 

That's a definite possibility. Rybag's reduced HSCROL DMA technique leaves lots of extra cycles. The four players could even have different gradients. Or the players could be overlapped for 3-color mode if the hero width is reduced. I am not a great artist though, so I'd need work with somebody on that.

Xuel on the game the guy it's PMGs only or you have also soft sprite using BACKGROUND (00) Black?

(What are the bit-pairs of Red, Green and Blue?)

This is so C.P.U. use that I think you are in trouble to have enemys, shoots, explosions,...?

 

About enemys, their explosions, coins rotation,... they seem pre-fixed at the same places, right?

Then for here maybe not hard to have them as soft sprites only.

 

But for our guy? Even if we, in some way get it as PMGs only (squeeze, change,...) we still need to have it's shoots as soft sprite.Have all guys (including ours) as soft sprites are C.P.U. out of question/impossible?

My idea is if you go my idea and have the sky all high Blue then I can have the contour of our guy as Black and his Eyes using the Blue of the sky and PMGs in different colours maybee possible to colour the guy using PRIOR0.

That's why, if you think it's possible our guy as soft sprite then I really need to know of wich bit-pair are each of the colours?

(and also have definitive colours and luminances for the PRIOR0 Oring)

Edited November 13, 2012 by José Pereira

[José Pereira]

Just saw you're Xuel.

Did you understand my questions?

[Xuel]

@Heaven

 

I'll post about the X/Y movement soon. See also.

 

@José Pereira

 

The current chromas are blue 7, red 3 and green 13. I'll try your suggestions tonight.

 

The demo has no soft-sprites. The hero consumes all four players and all four missiles at the moment. Now that the players are solid some of the missiles could be used for other purposes. If you don't mind background showing through the eyes and details or if 3-color players are used, then all missiles could be used. Also, DMACTRL/PMRez could be set to double-line to halve the sprite memory footprint.

 

There are about 23 character set slots in the current tile-set that are repeats of the sky. With some complication to the tile renderer, they could be freed up for soft-sprites. That doesn't give a whole lot of detail for enemies but it could be done. Consider that the hero currently covers the equivalent of about 88 character set slots since he's 32x44 effective pixels. The tiles could be reduced to 2x4, 4x2 or 2x2 tiles to free up more slots at the expense of background detail. Fancier soft-sprites will probably require dropping the frame rate. Back to the original topic of the thread , the line-by-line color swapping does hamper the CPU quite a lot, though less severly when using your swap-only-two-colors scheme and assuming some computation can be snuck into the raster period either by manual threading or by timer IRQs without degrading music/sfx too much.

 

I'm sure with some creativity, some balance can be struck that gives some more interesting results.

[Heaven/TQA]

Xuel... Just going through the code.., Jesus, another dasm/mads heavy user need to look closer at the table generator. Btw. The code lines with >>> are what? Remarks or are they doing something?

[Heaven/TQA]

I mean xasm

[Xuel]

@Heaven

 

Haha! xasm is the best. No I just got used to it and it's very fast which helped when assembling those huge movies I did.

 

The >>> lines are interpretted as Perl. All other lines are interpretted as print "TEXT" in Perl. See the Makefile.

[Synthpopalooza]

@Synthpopalooza

 

Nice suggestion. Here you go:

 

tiles-ntsc-synthpopalooza-lineshift.xex

 

I don't know how it works since I didn't do anything to swap chroma/luma on alternate frames. I just prepended an instruction slot to the display list and swap between $20 and $30 every frame. Maybe some missed WSYNC deadline just happens to delay the kernel by a line on the appropriate frames because of lower DMA on blank lines? Probably could get rid of the gray line on the top if I really studied it.

 

Suggestion: Add a DLI to the 96 instruction, that might fix it. So you will swap between 112, and 128+96

 

This technique is one I used when I was experimenting with alternating Graphics 15 and 10 every scanline. In that case, I had an effective resolution of 159x192 at 30 colors but with some flickering it seems. Used here though, it basically gives you the 160x96 resolution at 16 colors, but with no scanlines. There will be a few chroma and luma artifacts along the top or bottom of individual pixels but they are barely noticeable. And this is a great alternative for NTSC users (where PAL mixing does not work), as the higher refresh rate means the flicker is hardly noticeable.

 

Under Altirra it's best to use frame blending as the picture jumps if you don't. It should work really well on a real NTSC Atari (I haven't been able to test it though).

Edited November 14, 2012 by Synthpopalooza

[Creature XL]

With a Timer IRQ in this situation the only way to save is by having it as the only possible source (to save having to test status bits), and have the OS Ram switched in so the vector can be taken directly.

 

Yep, that's how I did it.

 

 

@missing sound channel:

Playing 8KHz (or even 16KHz) digis comes almost for free.

At least low notes should be OK. I am thinking about PWM-style basses.

Tests pending...

[Heaven/TQA]

almost for free?

 

Creature can you give me an example how to setup raster IRQs? a simple demo?

[Heaven/TQA]

@Heaven

 

Haha! xasm is the best. No I just got used to it and it's very fast which helped when assembling those huge movies I did.

 

The >>> lines are interpretted as Perl. All other lines are interpretted as print "TEXT" in Perl. See the Makefile.

 

ok... how does the VI-lookup table looks like? I am not into Perl.

[José Pereira]

O.k. sorry but need to add more things to this post.

So right one comes next--->

Edited November 14, 2012 by José Pereira

[José Pereira]

O.k. if my idea of changing just two colours reduce many cycles then there's still one more possible thing to do:

It seems you have: each Tile as (4bytes x 32 scanlines) and Playing Area has (7Tiles high = 224scanlines) then what about reduce the number of visible scanlines for the Playing Area?

I know that not many as you'll get small window to play but, if not 7Tiles high then 6Tiles high would be 192scanlines OR 6,5Tiles high that are 208 scanlines.

It seems not so bad, at least the 6,5 Tiles high.

 

For a (6,5 Tiles high = 208scanlines) you would get more Blank (16scanlines x 114) = 1824 cycles more

 

 

114

x16

-------

684

+114

-------

=1824

 

That are about more 90bytes for soft sprite AND/LDA/STA/OR

This 1824 with more only the two colours changes more about 1500cycles less for 208 scanlines that are about 3300cycles for free more that are 165bytes of soft sprite.

 

 

 

I think that if we want something on this Mode get into 224 or aproximate the 240scanlines of A8 visible screen Area will reduce greatly the game be possible (this or any other with even less or less sized sprites).

That's my opinion and have 208 or 216 or 224 doesn't seems a great difference (and you have to think that even 224scanlines for the Playing area then I presume you will have the others 16scanlines for a Status Area that even in ANTIC4 1Kb=1Charset will also need some cycles).

 

 

 

P.s.- The guy sprites it's 'in the making', just wait untill weekend for at least one or two frames and my idea (it seems possible to have the guy using 4Players in Multicolour and (Eyes more Pants) in 5th Player 4Missiles PF3 colour... just 2or3 pixels width reduced, all PMGs starting at same xPos and just need two DLIs VCS like to change two Players colour Register at scanline(s) at the middle of the guy (or maybe not)).

Edited November 14, 2012 by José Pereira

[Tezz]

Playing 8KHz (or even 16KHz) digis comes almost for free.

At least low notes should be OK. I am thinking about PWM-style basses.

Tests pending...

I'd be interested to see that too. The kernel I wrote earlier this year with a mode2/4 display had a 7.8Khz sample played every two scanlines.

[Xuel]

@Synthpopalooza

 

I have interrupts disabled so AFAIK adding a DLI wouldn't have any effect.

 

@Heaven

 

The comments are a little misleading. There are actually two tables for X movement. The first (veldirtable) is 256 bytes and is indexed by the facing direction (1 bit), the right/left bits of the joystick (2 bits) and the signed velocity (5 bits). Every frame, the old value (veldir) is ORed with the new joystick bits and used as the index to find the new value which has the joystick bits zeroed out ready for the next ORing. See here. So the table encodes a state machine or DFA that yields the new facing direction and velocity every frame given the old facing direction and velocity and the new joystick inputs. The logic of the state machine can be seen here. The Perl code just iterates through all possible input states and computes the output state for that table entry.

 

The logic is as follows:

1. Add one to the velocity if the joystick is held right but clamp at 15.
   
2. Subtract one from the velocity if the joystick is held left but clamp at -15.
   
3. Subtract one from the velocity if the joystick is neutral and the velocity is positive.
   
4. Add one to the velocity if the joystick is neutral and the velocity is negative.
   

Steps 3 and 4 simulate friction, though they act even when midair so that's some rough air!

 

The second table (veltablelo/hi) is 32 entries and is indexed by the signed velocity component of veldir to scale from a -15 to 15 range byte to a -16 to 16 range word. The result of this table is added every frame to xpos. This makes the fastest velocity scroll by exactly one character per frame since xpos is divided by 16 to get the coarse scrolling component. Note that the vel component of veldir is actually 0 to 29 and is shifted to -16 to 16 by this table.

 

veltablelo
:31 dta [#*16/15]-16
veltablehi
:31 dta [#<15]*$ff

 

For Y movement, there is a 69 entry ballistic trajectory table which encodes the y offset in screen space, so negative of normal graphing direction. The highest entry is the start of a jump. The apex of the jump is at entry 51. The entries below that are free fall with a terminal velocity of 1/2 tile per frame. The terminal velocity insures that collision detection doesn't miss any coins or platforms on a fall from great height. Here's a plot:

 

 

I just noticed after making that plot that the terminal velocity happens too soon which explains why the jump looks a little messed up when you cross that derivative discontinuity in the table.

 

Anyhow, when the hero is on a platform, the jcount index is set to the apex and the ground offset is set to the platform height. Every frame the jcount is decreased. If a collision with a platform is encountered, then jcount is set back to the apex and the ground offset is set to the current jump height modulo tile size. So, the hero is always falling even when at "rest", but he is readjusted back to standing still before any visual updates if he falls through a floor. If you move off a platform in the X direction, then you really do start falling because there is nothing to block you and jcount just keeps decreasing. When you jump, the jcount is set to start and the jump height of 3 is subtracted from the the ground offset. Y blockages are ignored for jcount values between start and apex. This lets you pass through floors on the way up but not on the way down. jcount can never reach zero because the map height is only 16 so you'll always fall into a pit before you get there.

 

@José Pereira

 

Indeed reducing the visible height frees up CPU cycles, so that's definitely an option. That's what I did to get NTSC working. I just need to come up with something useful to do with the extra cycles now.

 

Looking forward to putting your sprites in!

[Creature XL]

almost for free?

 

Creature can you give me an example how to setup raster IRQs? a simple demo?

 

 

Well, it's not xasm/mads. Instead its ca65 with macros of my own.

This is the first code I did. Meanwhile, it's a bit more

But, as said, lots of more to experiment. HAR'em holds me back right now.

 

Currently, I have two ISRs. One for color lines and one for lum-lines. So each ISR sets teh addr of the other.

This costs some cycles and IFF one uses samples one could use 8KHz timer (set freq to 1 instead of 0) and does it like that:

1.) set color values

2.) play sample

3.) pre load regs again

4.) (maybe sta WSYNC)

5.) set lum values

6.) RTI

 

Not tested, but sounds plausible. If I am missing something just tell me.

 

 

 

   ; Disable OS-ROM and IRQs.
	jsr    disableROM
	sei
	movei	0,IRQEN

; Set addr for ISR. ROM disabled!
	movei_w	irq_isr,$fffe

; Set frequency.
	movei	0,AUDF2

; Set POKEY freq to 15Khz ( each scan line)
	movei	1,AUDCTL

; Set to desired cycle in scan-line
	sta	WSYNC
	movei	0,SKCTL
	wait	98				 ; <-- maybe some changes here
	movei	3,SKCTL
	sta	STIMER

; Enable timer 2 IRQ
movei	2,IRQEN

	cli

; done 
:		jmp	:-


irq_isr:
	   pha

; Reset and re-enable timer interrupt.
	   movei	255-2,IRQEN
	   movei	2,IRQEN

; color changes
col_1: lda #0
  	   sta	COLBK
col_2: lda #0
    	 sta	COLBK
col_3: lda #0
         sta	COLBK

      pla
	  rti

[Heaven/TQA]

thanks, Xuel. as being years ago in pro games biz as manager (now doing e-commerce stuff) I realise that you seem to have more experience than only touching A8 for first time. where is your experience coming from? really only from A8 coding?

[Heaven/TQA]

Danke, Creature... need to look into it.

[Xuel]

@Heaven

 

I did a two year stint at a game company a few years ago. I've lurked around the demoscene since '93.

[Heaven/TQA]

aha... let me think of Austin... hmmm... Activision Blizzard? Bioware? NCSoft? SonyOnline Entertainment? Zynga? just to name a view "smaller" companies based in Austin... interesting... seems to be a gaming melting point

Edited November 14, 2012 by Heaven/TQA

[Tezz]

Xuel. Great to see a professional approach to game development.

 

@ Creature XL. Attached is my display/sample play kernel from the intro of a game conversion. With this procedure I reduced the resolution of the ripped sample data down to 7.8Khz to play at the correct rate over 2 scanlines. I'm intending next to play at 15.6khz every scanline. I've attached a non kernel example so you can hear the original sample before the resolution was reduced. This should be how the final procedure will sound.

welcome.xex

welcome - original sample - nmi skipped.xex

Edited November 14, 2012 by Tezz

[José Pereira]

Anyone here at RedRatSoftware in the old defunct/dead Fennel street 11 because this is real the worth of... The real old school!

Just kidding!...

[Xuel]

@Heaven

 

It was XLGAMES, a startup led by Jake Song of NCSoft fame.

[Heaven/TQA]

@Tezz

 

thanks for that... and thanks for not mentioning that sample got played when pressed space bar

[Tezz]

oops! yea it would have helped to mention that

[Heaven/TQA]

first I thought it does not run properly in Atari800Mac Emu.