Progress Thread - New demo - Cobra Mk III (18-May-08)

CompWiz · Post by **CompWiz** » Thu 27 Jul, 2006 1:04 pm

so, are you going to release a little demo of this? it looks great, and I'd like to see how it looks on calc.

Post by **kv83** » Thu 27 Jul, 2006 2:53 pm

CompWiz wrote:so, are you going to release a little demo of this? it looks great, and I'd like to see how it looks on calc.

Some posts ago he gave a link to a demo.

CompWiz · Post by **CompWiz** » Thu 27 Jul, 2006 3:54 pm

oh yeah. Somehow I didn't think of that when I posted. Well, I'll have to try it out. Thanks.

Post by **qarnos** » Thu 27 Jul, 2006 9:18 pm

Thanks for the tip, CoBB.

I have been working on another approach: I am keeping two screen buffers - one for the last frame and one for the current frame. When I send the data to the LCD I compare the two frames and only send the bytes which have changed.

There is a little overhead so in the worst case it will be a bit slower, but I wouldn't expect the worst case very often.

The initial version is not really optimal, but the results are encouraging. There's a small (about 1 fps) increase when 4 cubes are visible, but that increase jumps to 4-5 fps when I zoom right in to a single cube.

I will re-write the routine tonight and post the source, since it could be a benefit to quite a lot of games, especially low action games where the screen remains fairly constant.

CompWiz · Post by **CompWiz** » Fri 28 Jul, 2006 1:28 am

I tried out the demo and it works great. Nice job.

I can't wait to see what you do with it next.

Just curious, on the higher speed calcs (83+SE, and 84's) does it take advantage of the faster cpu speed? Just so you know, if anything, I've noticed that my 84+SE runs normal 83+ speed games at a bit slower than a normal 83+ would. My fps's were slower than the ones you got in the screenshot.

Post by **qarnos** » Fri 28 Jul, 2006 7:39 am

CompWiz wrote:I tried out the demo and it works great. Nice job.
I can't wait to see what you do with it next.

Just curious, on the higher speed calcs (83+SE, and 84's) does it take advantage of the faster cpu speed? Just so you know, if anything, I've noticed that my 84+SE runs normal 83+ speed games at a bit slower than a normal 83+ would. My fps's were slower than the ones you got in the screenshot.

Setting high-speed mode is just a matter of outputting certain values to certain ports so that's not a problem - I've just been lazy

. I will enable high speed mode in the next demo.

As for your speed problem - I assume this is because of the crappy LCD drivers some calcs have. The LCD takes longer than a "normal" calc to become ready after sending data - meaning the game will slow down too.

EDIT: I forgot about the most obvious problem - the FPS display is only approximate - it gets it's timing from the interrupt. If the interrupt funs faster than expected then it will report a slower FPS because it will calculate time as running faster. I have the expected frequency at 110 interrupts per second.

A while ago I wrote a program to estimate interrupt frequency against time by:

1) taking the average number of T-States required between LCD operations (which should take around 10us).

2) timing how many T-States between interrupts.

By using the LCD time as a reference I was able to get reasonable estimates... but that was before the buggy LCD drivers, which screw that method up.

Post by **kv83** » Fri 28 Jul, 2006 8:50 am

Maybe you should talk to Jim E. I think he has a reasonable method to get same performance on all calcs, since his Grayscale Package is on all calcs the same...

Jim e · Post by **Jim e** » Fri 28 Jul, 2006 9:41 am

qarnos wrote:A while ago I wrote a program to estimate interrupt frequency against time by:

1) taking the average number of T-States required between LCD operations (which should take around 10us).

2) timing how many T-States between interrupts.

By using the LCD time as a reference I was able to get reasonable estimates... but that was before the buggy LCD drivers, which screw that method up.

Actually i wrote a series of programs that measure certain timings, including LCD delay, interrupt timing, and cpu speed.
http://jim.revsoft.org/code

Post by **qarnos** » Wed 02 Aug, 2006 9:04 am

Thanks for that, Jim E. Interesting stuff.

It's a few days late but I finally got around to putting up that double-bufferef LCD routine.

Pros:
* Not much of a speed increase on normals calcs, but high-speed calcs should benefit greatly.
* Buggy LCD safe

Cons:
* The TI text routines only seem to deal with PLOTTSCREEN which is a pain for a double-buffered system, unless someone has written custum text routines to write to any buffer.

http://home.iprimus.com.au/qarnos/allcd.asm

Jim e · Post by **Jim e** » Wed 02 Aug, 2006 10:21 am

It shouldnt be that hard to rewrite vputs, lets see.

Code: Select all

Vputs:
	ld a,(hl)
	inc hl
	or a
	ret z
;do new line and return if you want
	call VputmapAnywhere
	jr nc,Vputs
	ret



VputmapAnywhere:
	push ix
	push hl
	push de
	push bc
	bcall(_loadpattern)
	ld ix,lFont_record
	ld bc,$0757
	bit fracDrawLFont, (IY + fontFlags)
	jr z,smallfont
	ld bc,$0559
	ld ix,sFont_record
smallfont:
	ld a,(penrow)
	cp c
	jp nc,Vputmapdone
	ld l,a
	add a,b
	cp c
	jp nc,Vputmapdone
	ld a,(pencol)
	cp 96
	jp nc,Vputmapdone
	ld h,a
	add a,(ix)
	cp 96
	jp nc,Vputmapdone
	ld (pencol),a
	ld a,h
	inc ix
	call spriteRoutine
	scf
Vputmapdone:
	ccf
	pop bc
	pop de
	pop hl
	pop ix
	ret

spriteRoutine:
;I have it using the same inputs as IONputsprite,
;so that one could be copied and used with varible address as the buffer instead.

I haven't tested that I just made it up real quick, but the idea should be sound. Theres alot of checking to make sure you have hit the wall, but a clipping routine would be nice in this place.

Post by **benryves** » Wed 02 Aug, 2006 10:31 am

The way I've checked timing in the past is very low-tech - in the interrupt, I've stuck something that toggles the status of the link port lines. I have a little PC program that tallies up how many times the status of either line has changed per second.

It works for a number of things, though - once I'd worked out timing, I added a FPS counter and moved the link-port toggling to the main loop (so it only toggles every frame) - and could then compare my on-screen FPS counter with the "real" FPS count timed by my PC, to check that they were accurate.

Post by **qarnos** » Thu 10 Aug, 2006 12:04 am

I have updated the demo again, although this time the cubes are gone.

The point of this demo is to test my BSP tree code, which will be used for depth-sorting and backface-culling each object (note for Ben: this is a full BSP tree, not the stripped back version I showed you).

So the cubes have been replaced by a weird looking object with a cross-type thing in the middle.

Additional improvements are in my object-culling code. In the previous versions it actually didn't work properly. It would correctly flag objects when the intersected the frustum, but not when they were entirely out, meaning objects which weren't even visible were still being transformed and clipped, etc. The FPS is now quite outstanding when rendering nothing

This version should also set high-speed mode on SE (and presumably 84+) calcs, although I don't own either of these, so it is untested. I would be interested in hearing how it runs on these calcs.

The demo file is as usual: http://home.iprimus.com.au/qarnos/democube.8xp

PTI:

Madskillz · Post by **Madskillz** » Thu 10 Aug, 2006 1:24 am

I tested it on a regular 83+ and then on an 84+ SE.
The Results:
83+ zoomed out and moving up or down I got a max of 64, zoomed in a rotating I got a wide range from like 13-17
84+SE zoomed out and moving up and down I got a max of 91 FPS and a fairly constant rate of 48-49 when doing nothing at all, zoomed in and rotating I got a wider range of 20-35

So I think the highspeed mode is working!

edit: I also got a bug...after exiting the program Mirage was telling me that all my programs were 0 bytes big. Once you leave mirage and return everything is back to normal.

Post by **qarnos** » Thu 10 Aug, 2006 2:24 am

Madskillz wrote:I tested it on a regular 83+ and then on an 84+ SE.
The Results:
83+ zoomed out and moving up or down I got a max of 64, zoomed in a rotating I got a wide range from like 13-17
84+SE zoomed out and moving up and down I got a max of 91 FPS and a fairly constant rate of 48-49 when doing nothing at all, zoomed in and rotating I got a wider range of 20-35

So I think the highspeed mode is working!

Awesome

The high FPS when doing nothing might be due to the double-buffered display routine I am using now. When doing nothing, almost nothing is sent to the LCD. That's also why the FPS display is flickery, since I am only drawing the counter to one of the buffers.

I might experiment with increasing the LCD frequency when in high speed mode, too. That might give a few extra frames per second, especially when there is a lot of movement on screen.

edit: I also got a bug...after exiting the program Mirage was telling me that all my programs were 0 bytes big. Once you leave mirage and return everything is back to normal.

Hmm. Interesting... I have hunch as to why that may be. I will check it out.

Post by **tr1p1ea** » Thu 10 Aug, 2006 4:36 am

Wow, that works blazing fast on my 84+SE, absolutely incredible!

The sorting and object intersection is probably the most impressive aspect of this engine so far. I also noticed that the polygon clipping still doesnt always clip right at the edge, but i guess its no big deal.