Lynx 3D Experimenting

[VladR]

27 minutes ago, Cyprian_K said:

 what about horizontal line? It is visible under Handy, but not on the real hardware.

I figured it out. That's the tgi lib. I noticed that when I do 10-20 runs, it sometimes shows and sometimes doesn't. But, if I flip buffers, it shows up.

 

However, my CPU drawing code always uses the same framebuffer pointer. Which means, that the tgi doesn't always start with same FrameBuffer, despite initialization always taking exact same amount of time.

 

Since, within next few days, I'm going to do my own double-buffering, there's no point in me trying to figure out what's going on with tgi and how to safely detect the currently visible FrameBuffer. At which point, I'll highly likely completely ditch TGI and go for pure ASM, I guess.

 

I will mitigate it by flipping framebuffers for half second in endless loop. Thus, every half second, you should see the results, regardless of which framebuffer tgi decided to start with.

12 minutes ago, bhall408 said:

 

Not surprisningly, I get same values as above for Handy on Android.

 

I saw the values others have seen for Mednafen using OpenEmu on Mac (which is Mednafen based).

 

Thanks for confirming!

[VladR]

Alright, here's second build:

lynxproj.lnx

 

Top Lines are done on CPU, bottom lines on Suzy. Purposely, as a secondary visual confirmation, the CPU lines are of two different colors.

Each batch is 10 lines (864px in total). The result is number of batches drawn in 128*64 us.

 

Under Emulator, I surprisingly get two identical values (triple-checked it by changing loop count):

 

This is the Suzy code:

	loop1:
		lda #10
		sta 165		; scanlineCount

		lda #50
		sta single_pixel_sprite_asm_ypos

		lda #16
		sta single_pixel_sprite_asm_xl+1
		lda #00
		sta single_pixel_sprite_asm_xl

		loop2:
				; Suzy Scanline
				; VIDBASL/H
		;	lda #24
		;	ldx #224
			lda #56
			ldx #192
			sta $FC08
			stx $FC09

				; SCBNEXTL/H
			lda #<(single_pixel_sprite_asm)
			ldx #>(single_pixel_sprite_asm)
			sta $FC10
			stx $FC11

			lda #01
			sta $FC91	; SPRGO
			stz $FD90	; SDONEACK

			@L0:    
				stz $FD91
				lda $FC92
				lsr
			bcs @L0
			stz $FD90

			lda single_pixel_sprite_asm_xl+1
			clc
			adc #16
			sta single_pixel_sprite_asm_xl+1

			inc single_pixel_sprite_asm_ypos
				; LoopNext
			dec 165
		bne loop2

			; Update 3 counters
		inc 1024
		bne loop1_next
		inc 1025
		bne loop1_next
		inc 1026
			loop1_next:

			; Check Timer Counter if it dropped below 50%
		lda $FD12
		cmp #128
		bcc loop_end

	jmp loop1

	loop_end:
		lda $FD12
		sta 1027

 

[VladR]

Question: Because on Jaguar, ObjectProcessor destroys its bitmap list while it's reading it (and one must reconstruct it each frame), I believe it's reasonable to ask whether Suzy behaves in a same destructive manner.

 

Ideally, all the registers VIDBASL/H, SCBNEXTL/H, SDONEACK would be only set once, prior to entering the scanline loop.

 

Reason I'm asking is that for high-poly cut-scenes, the number of scanlines will be ~1,000. Certainly, if possible, I'd like to avoid such expensive CPU work 1,000+ times !

 

Of course, if I had the HW, a test (for that) would be a simple, 10 minute build...

 

[+karri]

Suzy does not destroy any sprites while drawing. The same should be true to most registers. You can ditch the tgi libs completely. The relevant parts are setting up the interrupt.

 

Setting up an interrupt in cc65 world is done by the directive interruptor.

.interruptor IRQ

 

There is one detail about double buffering. Please swap the buffers in VBL interrupt. You could do it at any time but it looks ugly. From the main code you can set SWAPREQUEST and if it is set the code will swap buffers.

 

You set up the VBL interrupt by:

; Enable interrupts for VBL
        lda     #$80
        tsb     VTIMCTLA

I believe that the initial setup has already done all the other stuff for Mikey and Suzy in cc65.

IRQ:
        lda     INTSET          ; Poll all pending interrupts
        and     #VBL_INTERRUPT
        beq     IRQEND          ; Exit if not a VBL interrupt

        lda     SWAPREQUEST
        beq     @L0
        lda     DRAWPAGE
        jsr     SETVIEWPAGE
        lda     DRAWPAGE
        eor     #1
        sta     DRAWPAGE
        jsr     SETDRAWPAGE
        stz     SWAPREQUEST
@L0:
IRQEND:
        clc
        rts

Basically the code tgi_updatedisplay() is
 

SWAPREQUEST = 1;

The polling to see if the display is busy tgi_busy() is just

return SWAPREQUEST;

So there is really not so much code involved in the tgi library.

 

The new cc65 driver got rid of the IRQ drivers. I did check that the new drivers work but I don't remember how they do it. I am still a bit in the past with my coding.

 

[VladR]

Thanks. Vbl interrupt is really high in my to do list now

 

 

Reading docs, it appears that vbl lasts only 3 scanlines? That's not a lot of downtime. At 60 Hz, it's just 3*159 us = 477 us. That's just 7 iterations of my current 64 us timer. Of course, on LCD, I didn't expect same behavior as on Crt, but this is borderline unuseable...

 

i don't suppose there's a HW register that would change that behavior, right? Speed of line traversal is surely constant.

[42bs]

36 minutes ago, VladR said:

Thanks. Vbl interrupt is really high in my to do list now

 

 

Reading docs, it appears that vbl lasts only 3 scanlines? That's not a lot of downtime. At 60 Hz, it's just 3*159 us = 477 us. That's just 7 iterations of my current 64 us timer. Of course, on LCD, I didn't expect same behavior as on Crt, but this is borderline unuseable...

 

i don't suppose there's a HW register that would change that behavior, right? Speed of line traversal is surely constant.

There are the docs, check my footer. You can can increase the number of VBL lines, but on a real Lynx the display quality decrease. But 3 lines are at lot.

[42bs]

9 hours ago, VladR said:

Question: Because on Jaguar, ObjectProcessor destroys its bitmap list while it's reading it (and one must reconstruct it each frame), I believe it's reasonable to ask whether Suzy behaves in a same destructive manner.

 

Ideally, all the registers VIDBASL/H, SCBNEXTL/H, SDONEACK would be only set once, prior to entering the scanline loop.

 

Reason I'm asking is that for high-poly cut-scenes, the number of scanlines will be ~1,000. Certainly, if possible, I'd like to avoid such expensive CPU work 1,000+ times !

 

Of course, if I had the HW, a test (for that) would be a simple, 10 minute build...

 

Check the docs

BTW, Handy is quiet accurate besides cycles.

Edited July 3, 2019 by 42bs

[Cyprian]

Lynx II here:

[VladR]

12 hours ago, 42bs said:

There are the docs, check my footer. You can can increase the number of VBL lines, but on a real Lynx the display quality decrease. But 3 lines are at lot.

Yeah, the PDF I have doesn't have the list and description of registers, but I just discovered a link that actually has both, so I'll start crunching through that now.

7 hours ago, Cyprian_K said:

Lynx II here:

Thanks! But, there's no HW-accelerated lines. So, the Suzy code works on emulator, but not on real HW. Awesome....

At least it depicts a realistic performance difference (less than 4x faster, which sounds about right - e.g. 16 MHz vs 4 MHz).

 

Can anybody spot what's wrong with the Suzy code I posted few posts above ?

[+Stephen]

I also have a Saint SD card, and a McWill VGA screen.  I'll do my best to help debug this stuff.  Give ne some time to get gear out of storage, and figure out holiday schedule.

[42bs]

5 hours ago, VladR said:

Yeah, the PDF I have doesn't have the list and description of registers, but I just discovered a link that actually has both, so I'll start crunching through that now.

 

Are you serious? You "discovered" a link to the docs? Oh, please, don't start the same shit as in the Jaguar forum. Just wait that you find a bug in Suzy no body else found so far.

[42bs]

For the sake of completeness:

Copying 8192 bytes with the CPU takes on Handy 50ms and on a Lynx II 67ms

Drawing 102 unpacked 160 pixel wide 16 color sprites takes on Handy 33ms and on a Lynx II 17ms.

[VladR]

59 minutes ago, 42bs said:

Are you serious? You "discovered" a link to the docs? Oh, please, don't start the same shit as in the Jaguar forum. Just wait that you find a bug in Suzy no body else found so far.

Discovered/found/googled - synonyms.

 

 

Are we being semantic now? For few days I was indeed using one of the versions of the docs that is not as complete as another one.

 

I used to have about a dozen tabs with docs, when I posted the other thread then forgot about some of them and rediscovered them again just now. 

 

I really doubt I will find some new bugs without actual HW.

[+Stephen]

Vlad - I saw a comment between you & Heaven and Rescue on Fractulas was mentioned.  One of you - make it happen!!!  I've pulled the Lynx from storage, and I have a Saint SD cart, so I can test stuff.  Also, I have the McWill VGA screen, so perhaps I can make sure everything lines up.

[+karri]

On 7/3/2019 at 2:21 PM, 42bs said:

There are the docs, check my footer. You can can increase the number of VBL lines, but on a real Lynx the display quality decrease. But 3 lines are at lot.

There is an anomaly between Lynx I and Lynx II also. In Championship Rally The Lynx I froze in some cases. It had something to do with when you were accessing registers in relation to the VBL interrupt. The cure was to do all critical stuff just after the interrupt. I have a faint memory that changing the palette when Suzy was busy was a bad thing.

[Cyprian]

On 7/4/2019 at 2:07 AM, VladR said:

Yeah, the PDF I have doesn't have the list and description of registers, but I just discovered a link that actually has both, so I'll start crunching through that now.

can you pls post that link?

 

1 hour ago, karri said:

There is an anomaly between Lynx I and Lynx II also. In Championship Rally The Lynx I froze in some cases. It had something to do with when you were accessing registers in relation to the VBL interrupt. The cure was to do all critical stuff just after the interrupt. I have a faint memory that changing the palette when Suzy was busy was a bad thing.

interesting finding

[VladR]

8 hours ago, Stephen said:

Vlad - I saw a comment between you & Heaven and Rescue on Fractulas was mentioned.  One of you - make it happen!!!  I've pulled the Lynx from storage, and I have a Saint SD cart, so I can test stuff.  Also, I have the McWill VGA screen, so perhaps I can make sure everything lines up.

Of course I mentioned Fractalus. Last year, I already spent about a week of work on that 6502 texturing routine (for the space launch from the mothership) that you were so pissed that I didn't post any screenshots from.

 

In the interviews with ILM, they mentioned that were inspired by the BattleStar Galactica launch sequence. Except that they merely cycled some colors in the simplistic rectangular tunnel.

So, of course, that's exactly what I did - looked into how you can pull off a textured launch tube, even though no other game did. You have 4 base colors, but PMGs add couple more. Besides, in movement, at that resolution (160x192), with the Display List trickery, it looks absolutely awesome.

 

But Fractalus is sacred. There would be riots if I posted that I work on that, knowing that I don't have time to work on it next 6+ months.

 

Now with Lynx, that carefuly optimized texturing routine, is basically useless, as Suzy can scale any scanline at any zoom factor, at 16 MHz. Can't beat such raw megahertz power...

 

 

Which brings us to the next point. A Fractalus, with a 4 MHz CPU and 16 MHz Blitter, at least 64-512 KB of data on cart with 64 KB of RAM guaranteed - now that's a really potent combo. If you lock the framerate over the terrain to 10 fps, you got around ~350,000 cycles of CPU time + an insane amount of blitting bandwidth of Suzy. I honestly don't yet know what kind of terrain is possible with such power. That in itself is easily a week-long research endeavor...

[+karri]

Aah. An Elite style game.

 

I was seriously thinking about dusting off my Stardreamer for this competition. But my 3D skills sucks so fortunately I ditched it.

 

Perhaps we could team up sometimes in the future...

I would like to make an "Elite/Space suite zero" style game with a storyline.

[VladR]

14 minutes ago, karri said:

Aah. An Elite style game.

 

I was seriously thinking about dusting off my Stardreamer for this competition. But my 3D skills sucks so fortunately I ditched it.

 

Perhaps we could team up sometimes in the future...

I would like to make an "Elite/Space suite zero" style game with a storyline.

I would probably go even further and talk to Heaven, as he already has a real pretty terrain engine for Lynx, so we could perhaps just reuse that.

You could focus on the core gameplay (procedural content generation) and I could play with various engine cut-scenes (docking to BattleShip, jump gate, hyperspace sequence, planet approach, atmosphere descent, landing on BattleShip, Launch sequence,...) and space battle / Star Map.

 

Although, personally, if we go towards space action genre I'd rather work on Star Raiders II than Elite. Keep the frantic arcade gameplay and just keep hopping from one star system to another. That's a bit more achievable, as it doesn't need terrain engine, just the space battle, so it's much less work than Fractalus. All the eye candy I listed above is about 2-3 weeks of work. That's totally doable.

[+karri]

1 hour ago, VladR said:

I would probably go even further and talk to Heaven, as he already has a real pretty terrain engine for Lynx, so we could perhaps just reuse that.

You could focus on the core gameplay (procedural content generation) and I could play with various engine cut-scenes (docking to BattleShip, jump gate, hyperspace sequence, planet approach, atmosphere descent, landing on BattleShip, Launch sequence,...) and space battle / Star Map.

 

Although, personally, if we go towards space action genre I'd rather work on Star Raiders II than Elite. Keep the frantic arcade gameplay and just keep hopping from one star system to another. That's a bit more achievable, as it doesn't need terrain engine, just the space battle, so it's much less work than Fractalus. All the eye candy I listed above is about 2-3 weeks of work. That's totally doable.

Nice idea. Actually I already have the trading, the galaxy maps and the planet descriptions plus graphics implemented. There is also some steering implemented that mimics "Space suit zero". So you just target things and the ship will automatically follow your targets. The aiming cursor would be BIG.

 

What I would need is the eye candy for the enemy spacecrafts in 3D.

 

I would use a 360 texture sphere as the surrounding space. A tiled sphere surrounding the playfield. So I need no stars or planets - just the objects you can interact with. I really love the idea of visual past tracks instead of just moving dots.

There will be realistic space dust zooming towards you that reacts sensibly to your movement. 40 particles if I remember correctly.

Here in Lynx resolution and colour space.

  

 

In this model the camera view would move up/down/left/right only as the tiled background can not rotate.

[Cyprian]

2 hours ago, karri said:

 

I would use a 360 texture sphere as the surrounding space. A

sounds awesome

[+karri]

Thanks. A complete sphere would be 432 x 272 pixels. The highlighted portion is the size of the Lynx screen. Of course the graphics should be drawn so that the image can be folded from top to bottom and left to right without visible edges. The image would be tiled in 54 x 34 pixel tiles. The top left tile is also highlighted.

 

The obvious thing is that you cannot reach the planet by flying. It is just a space in which you can combat an enemy.

 

[Cyprian]

that's a lot of data - 117 504 pixels, 58k bytes in case of 16 color image

[+karri]

Well yes. But the RAM buffers are less than $2000 bytes. Besides I use packing. And I have a 512k cart. The image with the planet data and everything else is still small.

-rw-r--r-- 1 karri karri 82662 heinä  5 21:55 stardreamer.lnx
 

[VladR]

Damn, that sounds like at least 1,000+ man-hours project and here I thought my idea of new Fractalus was crazy effort-wise 

 

How long have you been chipping away at this ? You still got motivation ?

 

 

So, you can freely rotate the view, meaning ships can be anywhere in 3D space, right ? Like in a regular Space Simulator ? That's hard - given the implications on waypoints,  pathfinding, AI and especially debugging. I'd hate to debug that on the device via printing numbers on screen...

 

You obviously need a hand-tweaked LevelofDetail, as in Lynx's resolution, it'd be a waste of performance to process full ship mesh, unless it's right in player's face.

 

Those Engine Trails - that's going to be expensive - for 5-6 ships, you want a line traversal and it has to be 100% correct otherwise it'd miss the exhausts by few pixels, meaning you need a slow and precise line algorithm. Perhaps, via lookup tables, you might get away with FixedPoint, but that alone is at least 2-4 days of research and testing, assuming you already have some basic waypoint system in place already.

 

How many enemies do you want to have attacking at the same time ? 6-8 ? The AI alone will eat tremendous cycles. What's the framerate you think you're targeting ?