Project-M 2.0

[miker]

Hm... I do not want to bump just because, but...

 

How's Project M?

[Mathy]

Hello guys

 

Let's dump this thread.

 

Sincerely

 

Mathy

[AtariNerd]

A moment of false optimism was mine to be had. (As well to the others clicking my respone. Share it, you must.) Well, back to Grump norMalicy.

[analmux]

Any progress?

[NRV]

Sadly no.. (well, very minor).

 

Good to see you here by the way.

[TXG/MNX]

time to get this released as opensource a way to preserve this nice piece of software

[analmux]

Good to see you here by the way.

 

The same to you.

[AtarinDave]

I know you'll think I'm stupid for asking this, but, how do I run the Project_M file?

[NRV]

I know you'll think I'm stupid for asking this, but, how do I run the Project_M file?

 

Short answer: get last version of the Altirra emulator, run it, unzip the ProjectM file, drag and drop the PAL file over the Altirra emulator (configured for PAL, with 64K and PAL blending activated).. should work.

[ilmenit]

Btw, how did you plan to implement enemies? I've played with resolution used in Project M and it was very hard to show reasonable looking enemies.

[xxl]

gr.8 ?

 

[Rybags]

Same bandwidth though less CPU loss since the timer IRQs wouldn't be needed for mode change.

But doing higher resolution would mean the raycast phase would slow it down a whole lot more.

 

IMO the 256 colour mode looks way better. More colour at the price of resolution usually does.

Edited April 22, 2015 by Rybags

[Heaven/TQA]

@XXL.... does it run on standard 48k machine or some russian turbo clone?

[emkay]

@XXL.... does it run on standard 48k machine or some russian turbo clone?

Looking at the size of the screen, there shouldn't be any turbo used. We have seen much better "3D" on the A8 already, also.

[xxl]

@XXL.... does it run on standard 48k machine or some russian turbo clone?

 

 

standard zx spectrum 48 k....

 

his earlier engine (full screen on zx 48 k):

 

https://youtu.be/nCwZQ-ZnXlc?t=2m13s

[ilmenit]

An interesting thing is that there is no visible distance limit in the raycasting. I'd imagine that for performance reasons the limit would be to check max 4-5 intersections with cells.

[AtarinDave]

 

Short answer: get last version of the Altirra emulator, run it, unzip the ProjectM file, drag and drop the PAL file over the Altirra emulator (configured for PAL, with 64K and PAL blending activated).. should work.

Thanks.

[NRV]

Warning, long post ahead

 

gr.8 ?

That video looks pretty smooth, inclusive when reaching one digit frame rates. I suppose that's and advantage of the resolution and being monochrome.

I think I read something about the techniques he used (in a link from FormatWars maybe?). Doing some kind of eor filler, with raycasting only for the limits between tiles, but I could be wrong.

Anyway, doesn't look like I can reuse those ideas in ProjectM, maybe the raycasting one, but I already have one good optimization to implement there (that involves doing it with a binary search, to at least interpolate the final height of a row in between).

 

 

Same bandwidth though less CPU loss since the timer IRQs wouldn't be needed for mode change.

But doing higher resolution would mean the raycast phase would slow it down a whole lot more.

 

IMO the 256 colour mode looks way better. More colour at the price of resolution usually does.

Yep, I also prefer the 256 color mode, and wouldn't change it a this point. What I miss right now is the true two pixel per byte resolution in GTIA. Probably I will try to do it just in GTIA9 in that case and just reduce the number of rows.

I wouldn't like to use any external hardware acceleration for this, but I find it interesting that just doubling the cpu MHz in Altirra (65C816, 3.58Mhz), almost get the frame rate to 50. I don't know if the IRQ's are taking time in that case (because they look broken), but is a good scaling.

 

 

An interesting thing is that there is no visible distance limit in the raycasting. I'd imagine that for performance reasons the limit would be to check max 4-5 intersections with cells.

Yes, that's another good thing in that demo. I don't have areas that "open" in ProjectM, precisely to control that.

You could set the limit as an option in a menu, so the user decides, but there is no point in searching for a collision beyond the minimum height of a wall.

Good thing if you have a game with limited visibility, like a dungeon, where you only see black/darkness beyond a certain distance (or some kind of fog.. GTIA9 again, hint, hint).

 

 

Btw, how did you plan to implement enemies? I've played with resolution used in Project M and it was very hard to show reasonable looking enemies.

From the graphic side I would choose doing them just in the same mode, like the barrels in the first demo:

http://www.atariage.com/forums/topic/148697-project-m-stage-1/

 

Direct conversion:

Hand made, first version:

Hand made, final version:

 

I did some graphics tests using Player/Missiles.. original one:

My version with a couple of line color changes:

But it takes too much time for me to do something like this (I'm not an artist x) ).

I would prefer to use the P/M for small projectiles and shot effects, maybe for the main weapon or other overlaping static effects.

 

The two barrels in the first demo (precompiled sprites), have a load of like 5fps in a 20fps system, approx. So if I were to put them in the current ProjectM, I would get frame rates between 15 and 20 probably.

 

From other thread:

 

If this is the case --- then it seems the only way to get over it, is to have hardware assistance - taking it away from standard A8 hardware software... not desirable but maybe the only possible solution for a good outcome...

I have already decided in using the 8Mbit cart. It's just more memory and would allow me to do everything I want (more wall variations, pre compiled sprites, animations, recovering the smooth rotation from PM 1.5 .. go take a look if you don't remember).

No need for hardware assisted DMA or other things, but the code could adapt and give you a better frame rate if you have a better cpu.

 

Still, to turn it into a full-featured FPS would involve a lot of CPU power needed for large sprites that must be resizeable, clipped when moving half-way behind walls, with collision detection etc. Actually I do not wonder that the work has stalled at the current phase.

Nah ... I have seem this from time to time, and my answer is still the same. I don't have much time these days (for the last years I should say).

Also I'm not good working just a little everyday, so is not technical problems that have stalled this. In fact, I don't see any major problem ahead.

 

Neither sprites, collision detection or AI are great problems.

- Clipping: for precompiled sprites you can reorder the code in "sprite rows", then clipping a row is just comparing the current sprite distance to the camera with the distance in the world "row Zbuffer", and then starting (or ending) the draw at the correct row.

For P/M's it would work in a similar way and at the end just setting a mask, used to draw the P/M.

 

- Collision detection, AI: is basically a 2d top down world. First, I don't think you need to have that many objects active locally.

For projectiles is basically a couple of X/Y comparations, or tile comparations (against walls for example).

For enemies you don't need to start doing A* for this to be fun . Lot of "2d games" (like PacMan, Robotron, Eidolon, Encounter) have ideas that can be used to move enemies and get interesting behaviors.

 

- Sprite scaling: here you don't need to have scaling code. You could use some scaled frames in memory (not all sizes) and still have a good effect (like in Space Harrier). Eidolon don't do any scaling for example.

Also, in the Spectrum demo the sprites appear and disappear at certain distances, and it still looks good.

 

There are still more optimizations and tricks that can be used, to improve speed and visuals.

Hiding sprites background (not drawing the world in the same rows). I don't like this, but could be an option for the user to decide.

There was a recent Spectrum demo of an rpg with a 3d view here, that I don't remember the name, but the interesting thing was that they never did "scale down" of the graphics, only scale ups.

So you don't see the typical artifactings in the walls, at certain distances or while moving. That's an idea that I would like to test to improve visual fidelity, for example.

 

 

Regards.

[NRV]

I forgot to mention that, for the next step, I need to reorder the code and start using the banks in the 8Mbit maxflash cart.

But I don't know much about cartridges in general.

My idea would be (if possible) to generate an Altirra maxflash cartridge, directly from Mads.

For that I need to be able to assemble different code with the same address (the 8k bank/window), and also generate any kind of header and checksum info that is necessary.

 

In my case the first thing I do is deactivating the operative system and using all the memory, so no need to follow the OS guidelines I suppose.

So anyone that can put the simplest code to do this (or a link to the info), would be of great help.

I believe it should be possible, but normally I have seen people using external tools to generate the final cartridge code.

 

 

Related pictures:

 

http://www.indiedb.com/games/starshock

 

Related videos:

 

 

Related game: (to farm for ideas x) )

 

http://phoboslab.org/xibalba/

 

 

Regards.

[Heaven/TQA]

You still use OS? I thought already switched off. Will post later my "startup code"

[Heaven/TQA]

here is the NMI code of Arsantica 3 Intro... I am sure you get it...

 

.proc NMI
bit $d40f
bpl VBL
jmp dummy_dli
dliv equ *-2
 
VBL
sta regA
stx regX
sty regY
sta $d40f ;reset NMI flag
inc 20
inc fps
lda #<top_dli
sta dliv
lda #>top_dli
sta dliv+1
.if shaking_flag=1
lda 53770
and #1
asl
asl
asl
asl
ora #$80
sta dlist
.endif
lda #$90
sta $d01a
lda #$70
sta $d01b 
;this area is for yours routines
jsr pm_init.set_ship_pos
.if music=1
jsr rmtplayer+3
.endif
; lda #$fe
; sta $d301
lda #0
sta kernel
sta $d011
quit
lda regA
ldx regX
ldy regY
rti

[Rybags]

Wouldn't it be more cycle efficient to just have the code stub before every DLI and just change the hardware vector directly each time DLI address needs to change.

e.g.

 

 

jvbi1 jmp vblank
dli1  bit nmist
  bpl jvbi1
; code for DLI #1 here
;
  rti
jvbi2 jmp vblank
dli2 bit nmist
bpl jvbi2
; code for DLI #2 here
;
; and repeat for each extra DLI

[Heaven/TQA]

the question is... can anyway (due to careful planning) VBL occur in DLI1- til last DLI?

[Rybags]

???

 

A DLI can occur on the 240th display window scanline and the VBI occurs on the following one.

Memory fuzzy on this but disabling DList instr fetch DMA repeats mode, and I think that includes requested DLIs.

Unsure if invoking the scanline 240 hires bug would cause DLIs to keep triggering beyond normal display, my guess would be since only PMG can be shown in that area it's a case of probably not for DLIs.

[Heaven/TQA]

why do you need that:

 

jvbi1 jmp vblank
dli1 bit nmist
bpl jvbi1

 

if it can not appear in middle of screen?