object list

[Otto1980]

Hi all,

 

can you guys explain me what the "stop object" is for?

what it does and is it urgent need?

 

thanks

greetings

[+CyranoJ]

It denotes the end of the object list, telling the Object Processor to halt for that line. Without it, the OP will run forever, or, more likely, until it crashes.

[Otto1980]

Your my Heroe.. answering this noobish question.. sorry for that.. after reading a little slower the v8 doc i saw it by myselfe (and couldnt delet this stupide question from forum :-(

 

btw

 

as im now trying getting into the objectlist-refresh mechanism i ask myselfe how much ready the jag is after the standard startup.s in the example

the objectlistroutines... can they be used in the rest of a project? maybe small modification of for example "#license" and "#BMP_PHRASES".. just doing it a little more common for other values accessable

 

im asking this because as i saw on the "TESTRGB" demo source there is the identical Subroutine "InitLister" <-> "make_list" just with some other imputvalues like "MY_LISTSIZE" in stead of "LISTSIZE"

 

my goal is to understand the objectpart completly and create a nice and common startup for my further coding

 

greetings and good night

[+CyranoJ]

Well, the Object Processor trashes the list as it processes it meaning you have to do one of the following:

 

1) Fix up the broken parts of the list every frame

2) Create a fresh list every frame

or

3) Make a copy of the list (a shadow list) and blit that over the live list every frame

 

The easiest is the 3rd method because then you don't have to do all that crappy time intensive bit-shifting more than once.

[ArneCRosenfeldt]

You are supposed to have your game objects in C# with the properties your game needs. You then write out a display list for the OP. In any game with 60 fps action, the list is fire and forget. If you do slower games, you are supposed to use a frame buffer and set it to the correct double buffer mostly hard coded in your interrupt routine.

 

For performance you need to clip some values while you write the list. So in a way you already trash it on write. It is like the sprite multiplexing on C64. It is low level.

[Ericde45]

as you are talking about Object list, an additionnal question :

 

if i want to use lots of sprites, i think i need to use several object lists, so that the object processor does not read the complete object list for all lines ?

so shall i put some YPOS < x test every N lines and bra jumps ?

or is there any way to have object list for 0 to N lines, then object list for N to N*2 lines, and so on, N*2 to N*3, N*3 to N*4 etc until 256 lines ?

 

 

[swapd0]

You have to create a tree with branch objects, the leaves are lists with the sprites.

 

[+CyranoJ]

3 hours ago, ArneCRosenfeldt said:

You are supposed to have your game objects in C# with the properties your game needs.

Glad you are on board with making super efficient code.......

 

Although I suspect the irony of that statement is lost on you.

[ArneCRosenfeldt]

I like C#. It avoids a lot of pitfalls like in python which is always slow. Both have GC. C programming language needs to have everything volatile. In C# or at least in Java you don't have pointers. You can let the runtime move objects around.

ARC in objective C only tells you the number of references. You cannot iterate and update them. With only 4k SRAM this is bad.

[jguff]

Is there now a C# compiler for Atari Jaguar?  Python as well?  Either would be a big step up from the 32 bit Primate compiler i'm using...

 

Bob

[swapd0]

Pointers are cool!!!!!!!1!!!

[ArneCRosenfeldt]

Not full blown, but people already compile IL to C and also AOT-compile for iPhone . Would just be funny to grab a simple, modern Unity3d example and write a compiler which works for this and then go from there.

On 1/25/2022 at 2:17 PM, jguff said:

Is there now a C# compiler for Atari Jaguar?  Python as well?  Either would be a big step up from the 32 bit Primate compiler i'm using...

 

Bob

 

[DEATH]

On 4/11/2013 at 12:50 AM, CyranoJ said:

Well, the Object Processor trashes the list as it processes it meaning you have to do one of the following:

 

1) Fix up the broken parts of the list every frame

2) Create a fresh list every frame

or

3) Make a copy of the list (a shadow list) and blit that over the live list every frame

 

The easiest is the 3rd method because then you don't have to do all that crappy time intensive bit-shifting more than once.

The simplest way is rather a mixture of 1) and 3) (at least for small projects) and this is what is done in the examples of the Atari development kit: save the 2 parts that are corrupted and recopy them at each vbl

 

move.l #listbuf+BITMAP_OFF,a0
move.l bmpupdate,(a0)
move.l bmpupdate+4.4(a0)

 

Ok, it's good for 1 object

[+Gemintronic]

On 1/28/2022 at 3:57 AM, ArneCRosenfeldt said:

Not full blown, but people already compile IL to C and also AOT-compile for iPhone . Would just be funny to grab a simple, modern Unity3d example and write a compiler which works for this and then go from there.

 

 

One could easily port EmuTOS to the Jag and then run any Atari ST C compiler you want.  Surely with the right transpiling software you could take a Unity3D example from 2022 and run it directly!  C and C++ and C# are the same whether iPhone or Atari Jaguar, right?

[Cyprian]

6 hours ago, Gemintronic said:

 

One could easily port EmuTOS to the Jag and then run any Atari ST C compiler you want.  Surely with the right transpiling software you could take a Unity3D example from 2022 and run it directly!  C and C++ and C# are the same whether iPhone or Atari Jaguar, right?

I started porting EmuTOS to Jaguar last year with some success.

Unfortunately I stuck on "move #$2700,SR" instruction, which are placed  in a different EmuTOS places and it appears that it can blocks the VBL interrupt.

Missing VBL interrupt means missing set of the Object Processor list and finally destroyed ram by the OP and EmuTOS crash.

I have back to it and find a workaround.

Edited February 28, 2022 by Cyprian

[+Gemintronic]

@Cyprian

 

Holy cow!  I was just joking around but that sounds amazing!  My own fevered dream is something that can bootstrap an AMOS or STOS BASIC game (which probably need calls to TOS).

[42bs]

8 hours ago, Gemintronic said:

 

One could easily port EmuTOS to the Jag and then run any Atari ST C compiler you want.  Surely with the right transpiling software you could take a Unity3D example from 2022 and run it directly!  C and C++ and C# are the same whether iPhone or Atari Jaguar, right?

Matthias Domin had TOS running on Jaguar already in the late 90s.

[dilinger]

12 minutes ago, 42bs said:

Matthias Domin had TOS running on Jaguar already in the late 90s.

http://www.mdgames.de/tosonjag.htm

Including hardware.

[Chilly Willy]

4 hours ago, Cyprian said:

I started porting EmuTOS to Jaguar last year with some success.

Unfortunately I stuck on "move #$2700,SR" instruction, which are placed  in a different EmuTOS places and it appears that it can blocks the VBL interrupt.

Missing VBL interrupt means missing set of the Object Processor list and finally destroyed ram by the OP and EmuTOS crash.

I have back to it and find a workaround.

 

No idea how Matthias did it in his port, but it sounds like the best thing for you to do in yours is to disable all but the VBL and set a critical flag that tells the VBL handler to just repair the OP list and exit without doing the normal vblank routines. When the SR is restored and ints are enabled, you can clear the critical flag so the vblank runs like normal.

 

[42bs]

Or let the GPU handle object list Update/restore.

[Cyprian]

3 hours ago, Chilly Willy said:

No idea how Matthias did it in his port, but it sounds like the best thing for you to do in yours is to disable all but the VBL and set a critical flag that tells the VBL handler to just repair the OP list and exit without doing the normal vblank routines. When the SR is restored and ints are enabled, you can clear the critical flag so the vblank runs like normal.

I'll try to look onto Matthias code then

 

2 hours ago, 42bs said:

Or let the GPU handle object list Update/restore.

nice idea, I'll try that