Symmetry of TNG

Would if i could!

Wish France were closer to the bush where i live ;P

 

A "request" would be live 24h video =) then I´ll be online and atleast be there viritually =)

 

Hope you guys have a nice time!...

cheers

/Symmetry 2 far north.

I don't like that comment

 

Why do I have the feeling you've played with the Alpine's debugger a lot ?

 

if you can mathematically proove me otherwise I will change the statement ;P ..was speaking strictly mathematical offcourse!

 

No actually i never got it working (except 68K part) ...that is actually an "educated guess" based on blitter knowhow and how I would have done the same effect myself...

No if I am to debugg/dissassm something I move the code to my falcon and use DevPac.... its the only debugger i know & like.. which is a terrible jobb if it is a bigger-than-floppy file hence I usually never debugg... its just a matter of wrighting correct code from the start... which is a piece of cace on the jaguar *joke*

=)

 

Well I would say that the statement is 100% true.. but.. to take mathematical terms the statement "does not commute" =) ....ie 65536 encodes as 0 (since the 1bit set bit will be above the word length & hence will be skipped & value ends up beeing 0) ...They did not say the other way around was true... ie "0 encodes as 65536)...zero is zero.. ...(note: zero^2 is also still zero

 

Ahh.. ok the a1_clip thing.. well that is forbidden territory 4 shure.. (kind of took that as default since it is explained everywhere in the devman ;P

--but it is interesting to hear exactly where it happens...

 

Its funny how stable Tempest2K is considering it uses the clip function ALLOT!..

but i guess it can be used ASLONG as you follow ataris rules when not using it!... (then clear the clip function!") If you use the clip function, you will have to set it to zero everywhere you dont use it!..

 

 

but my point is that one should not clear a buffer in that way (ie bcount, y=1, x=maxvalue) eventhough it works as long as the memory is linear and the buffer is not bigger than 32768 pixels... but rather use the "window" fashion... stepx,stepy,widthofwindow and so on... it always works, you can clear whatever you want (smaller square part of window, phrase interleaved windows, make "clr-effects" by for example first clearing even, then odd lines.... and so on)

 

phr interleaved screens WILL one day be usefull to all of you anyhow.. so its better to get used to it

(example: even in a 2D shooter you can interleave screens,objects with sprite data!... that way there will be less memory pagefaults when acessing the sprite data..... clearing every 3rd phrase in a chunk of memory is then easy donw with the blitter using the step functions...)

 

 

 

if someone is interested I might still do some examples..???.... (so people dont have to reinvent the weel for each thing..!...? just trying to be nice/helpful.

 

/Sym

just a quick reply.

 

I get the feeling that the blitter is not quite understood here =) ....If i get time this weekend i will trye to show some basics.

 

to put $28000 to clear 2*32768 os not a "workaround" its the way it is supposed to be! since b_count is (ycount<<16|xcount) ...working in a window fasion.. the blitter will clear xcount pixels (32768. inner loop) ...then step back with A-step pixels in x direction.. step A1Ystep in y direction (outer loop) and then reenter the inner loop..

...?... no that made no sence at all =) sorry its friday afternoon, micro holiday! =P and I will post some stuff later explaining better.

Last thing though.. I have never ever had the problem of a clrscreen missing pixels... so you must be dooing something backwards... but keep Hacking all of a sudden you find a usefull bug ;P

 

cheers

hehe ...works if you are not ashamed of it ;P

myone beeing a total experimental test routine not well written in any way but just to get the code running... (2yars old routine for that mater).

 

Sorry for this next "patriotic" line but recent external events has awoken this "childish" behaviour in me:

---It would also be nice if it was only downloadable by registered Jagware members...---

I do wanna promote & help fellow hardworking!/hardcoding! JagWare coders!...

The rest i dont realy care for much atm... (sorry).... it will pass.. but untill it does.... Jagware is the way to go!... So you who get this keep it to yourself...

 

I could start by sending my sheit-code to you to (seb & txg ...600Kb of mail heading your way.. (txg i hope i still have your mail..if not PM me).

 

If you want a better "public" example we will have to turn to Zerosquare & do some begging ;P

 

 

 

cheers

/Sym

Well Starcat I could mail you my code (as it is) ...as long as I dont have to comment it any further =)

Ie no time to alter or comment it, but time to pack it & sent it to you would be ok...

then atleast you would get my AvP testpic of 640*480 to display and you could take it from there...

 

(warning of unclear code though!.... made in a hast years ago).

 

 

Will check if i can figure out your email and youll get it...

 

cheers

/Sym

Walk the mindfield! =)

 

I have had problems having combinations like:

 

moveq #1,Rn

addq #1,Rn

 

inserting a NOP between them gave ok result... (reading my commented devman).

 

So one should defenitely beware of the write score bug!...

Safest bet is to never use the data on the secound line but 2steps away... (depending on case).

but to use pipeline optimisation you need to know when the result is written back... ....its almost never easy...

 

 

---------Note though:

Instead of using the "or rn,rn" thing use:

 

cmpq #0,Rn !!!!!

 

since the or itself has a writeback... (which can cause trouble). the cmpq dont have a writeback and is hence faster.... (though it alters flags!)..

That is your standard atari example.. and it shows in theory how it should be set up yes.. but as you can se there are allot of places where it can be optimised. (will not go into that though).

 

I just wanted to say that you should all take some time to dig into the blitter info and trye to understand what is going on. It is not like your 68K clrscreen rout nor the falcons blitter.. it is one of the coolest chips in the jaguar =) ..(and the buggiest... which shows that Atari was consistent with Jin&Jang

 

The fact that it is in pixelformat is what makes it so easy to understand once you get the hang of it.

This is also important when you take a step up and start to interleave screens & Z-buffer in 3d code (for example). having anything else than a pixel representation will sincerely mess up your mind ...but if you use a pixel rep. then you just have to add a "pitch" value to blitter&op flags and thats it! (almost).... and then you have 3 interleaved phrasescreens (2screen+1zbuffer ...OR for example spite data/gfx if you want to optimise your "non OP 2D engine").

 

So i mean understanding the blitter is a good thing.

 

 

--regarding "dropouts" in poly drawing:

if you set up the blitter to always draw in pixelmode... and you still have the problem then the problem is probably something else.. (calcs, clipper, or perhapps faulty pixelmode setup rout)...

But if you trye to use phrasemode blitting to draw your scanlines then you most probably have a phrasealignment issue... some cases are impossible to draw in phrasemode.. and either you get problems or you have to switch to pixelmode ...thats just how it is.. and to get a glitch free rout you need to take care of it "by hand"...

 

enough talk for now =)

cheers 2 all blitter fans

Grattis på födelsedagen Az! =)

 

(well everyone else is going for native tounge so why not me

 

Cheers!

Ahhh!.. am I to late? =) ..if not

 

Happy Birthday!... may fortune come your way today.... (like SuperBurnout source fall from the sky straight into your hands

Well... i hope you didnt "waste" your birthday wish on something else, or did you ?

 

salut!

/Symmetry

shame on all of you.

 

..desiding if I'm to be offended by that post or not... but... nahh... I dont take it personal since I dont have any reason to.

 

I just what to point out that there is NOTHING special about an old RS485 protical from early 80ies and i know of atleast a dusin people here that would be able to do that IF they had the chanse (equippment) and took the time to do it...

But instead Im playing New cd games for the jag.. released by coders here.... and that is actually better than having a protocall in my hand..

 

 

But I must agree that we should not abandon the idea of investigating the bug, nor the protocall solution just because there will be a new HW that has better UART.... we still need a good protocall even if the HW is "error free" to handel setup of multiplayers and sending the data around... (this is actually a verry simple problem if you start to think about it, and you dont need 10years to finish it!).

 

And also I would like people not owning a JagCF to be able to play future net games.. and hence it would have to work on a "standard jaguar UART device"...

thats my oppinion..

 

so keep investigating in any way you see fit! =)

cheers

Depending on the depack rout I would imagine the final "throughoutput" in bytes/s would depend on the type of data beeing depacked..

Atleast thats the case when packing it.. It takes different time to pack depending on how "complex" the data is.... and unless im mistaken the situation is similar when depacking...

Depacking a sprite with mostly black areas takes shorter than one with allot of unique , varying, pixels...

 

IF i understood correctly.. though I never had to pack anything for the jag ..yet =) ...

Like AMD rev.engin. Intel.. and se what happened to AMD, they got sued & died did they not? .... =) *retorical question, dont answer *

There are legal ways to get around the law and avoid a lawsuit. (Haha... that sentence sums up the stupidity in legalsystems =) ..anyhow..

 

>but certain people would get very angry with us

That is true... since his "life work" would be public domain, every game from there on would have that feature, and that "unique" feature of their game would be lost...

I think this might be a major contributor as to why the "trick" of how to get it to work hasn't been revealed yet . That and the fact that there is no real UG-game out there that is "there yet"... meaning that perhapps he would help out with that part if we had a full flagged, good game out there, soon to be released...

 

BUT point beeing that There seem to be some horrible timing issues with it, and IF you ignore these from the beginning, and build your game dissregarding them, I would assume that if you later learned how to get the UART working (by some kind person) you would have to rebuild the hole code!...

 

So I mean if the will to help was there, atleast general hints on what Not to do, would be given to the public.. or atleast to the UG coders..

So I would assume theory1 holds untill prooven wrong (basic scientific prinsiple

 

>stabylo

No the cart encryption is not a problem as such.. (since the data on the cart is not encrypted).

But dissasembling any program is no easy task.. and we can be sertain that the data is packed to save space, which is a much bigger problem for a dissasembler. in worst case you need to run the dissassembler code of the orignal program to get it working properly.. which means hours of tracing through the code on the cart.. (avouding hangs)...

 

Added to the difficulty is the fact that the jaguar has 3 different processors... with atleast 2 different languages... (3 if you are harsh). making a dissass even more difficult.

 

Im not saying itis impossible Im just saying its not realy easy!... which means that we would better spend time on developing our own code... or atleast start with the higher protocalls.

Or instead of the obsession of hacking the code, spend time on writing an actuall game...

 

Though I know everyone loves a challange

 

cheers

/Sym

>Azrael , Ray, Symmetry where are you ? SebRmv want to play !!

 

hehe =) ...Im buzzy! =) ...and the following days Im babysitting my sisters daughter 10months.. I will diskuss the solution with her ;P

 

 

 

>SebRmv

>I would like to see an example of Gouraud Shading and/or Zbuffering for example.

 

well i have debugged some gouroud shaded lines in my life.. and have a rather good understanding of what is going on, and the limitations that exists (and the workarounds that might be needed).... but by the time I have written a howto you have made a well written tutorial in nice looking pdf format

 

regarding zbuffer I have a realy cool effect i made some year ago when i thought of what the zbuffer could be used for (that demostrates the zbuffer good).... BUT... as with the interlace routine I would have liked to keep this effect "secret" for a possible upcoming megademo.... =)

And i am hence a bit torn what to do.. =) I would so much like to show you all, but then the "wow" effect is lost.... (most important in a demo .. I dont know what to do =)

And as with interlace its possible that this effect is thought of rather soon here since you are hackers

 

I could and will however, trye to answer any questions about the topic that might come upp....

Perhapps I can incorporate the zbuffer example in a gouroud one... well se how much time i get, or/and if these topics evolve here at the forum.

 

great job with the rotation btw!

 

cheers

/Sym

Beeing one of the "forgotten" I just want to say that I think it is good for poeple to get another, more detailed, description of what is going on when doing rotations & how to do it.

So people can understand that the jaguar can do rotations pritty easy!

 

The only thing "bad" about it is that the rotated bitmap will use more space in memory.. (depending on form of object, sometime the width will be as wide as the diagonal).

 

And to do this easy you either need to make extra space from the beginning (if you use obejcts). Or you will need to have an elaborate mem management scheme... OR easiest way is if you use a framebuffer....

 

 

But its good & usefull information! =)

 

salut

 

btw... "forgotten" ..theres a new group name.. perhapps i should change

 

/Symmetry of the Forgotten

Thank You ALL for the greetings! =)

 

It is verry much appresiated!..... honestly!

 

 

 

Beeing a coder Im used to representing numbers in different bases, in particular Hexadecimal.

 

So it is with a verry glad feeling in my heart, here on my "20th" birthday ..i say a BIG:

 

 

THANK YOU ALL!

 

 

regards

/Symmetry ..merely $20 yo

so its raytracing, nice! =)

 

well source are always nice, and Im interested in the topic, and I could do a quick check if I notice some obvious optimisation possebilities. So if you whant to, then please do so =)

 

(I have some PC c source for this that i planed to dig into & convert.. but i never got to that..

 

>shadevalue is calculated doing crossproduct

you mean DotProduct? ... ..but still... you mean you do a cross product at each pixel of the sphere to find the normal & then do a light*normal to get the shade.. thats still ALLOT of work.. (and it is the true "algebra way".... then it isnt that bad speedwise =)

 

 

>signed .8 (else I think it will overflow)

well it might still overflow of you do MAC's ..but with s7.8 (signed 7integer 8fixpoint) you get the correct sign with the built in mult instructions.. If you go for s15.16 then you get higher precision but you ned allot of more work

 

 

>I use external storew

Well if there is nothing else on the bus then perhapps.. but in worst case 1 storew will take the time it takes for the OP to do all objects in the objectlist!... since the OP hogs the bus while it is doing the OL, then storing internally is a much better way since it can always do that independently of what the other system is doing.

 

I did this when i did the maniac optimisation of my fire routine... first version storew'd ..and it becomes much much faster to build a scanline internally & phrblitt.

I noticed this even more with the "water" routine i made... (aarrgghhh!) ended up with a circular scanline buffer that was phrase blitted in & out, and calculated 2pixels at a time with half the loopcount.... and that was extremely much faster than doing 5 or 6 external mem accesses for each pixel... but it becomes a heck of alot more complex...

ahh well...

 

Its still nice work you did! =)

And it IS usfull!... i can imagine a 96K TYS demo and that could be a "gfx renderer" instead of storing the bitmap ..so..

 

chers!

>SebRmv:

Ahh.. ok ...well i dont se why that PC relative thing would not work... once in the irq those instructions are just ordinary ones... unless there are some horrible bug that "move pc" can only have ordinary bank as destination,not the alternative... but... it should not!... please keep us informed of any progress... (even if it is realising that you did something wrong) Its just good to know what can and can not be done in an irq....

 

 

 

>Orion:

one might think that yes... but ONLY if the gpu and blitter is not using the external memory... (and usually they do, ie gpu doing calcs & setting up some blitter instruction & starting the blitter. Then doing some 68K instructions is kind of futile.. since the priority of the 68K under normal operation is lower than both gpu&blitter... ie the 68K will be halted untill they are done.

Instead you might end up "hogging" the bus with a long latency 68K instruction.. and the gpu&blitter have to sit & wait for the 68K to be done...

So in long run if you want Full Power.. you should aim for not using the 68K at all.. or as little as possible..

 

ie do a loop like:

 

mainloop:

-short OPTIMIZED! 68Kasm code

-stop instruction

-bra mainloop

 

the 68K will do its thing, shut down & stop hogging the bus (OBS not a small loop since each instruction will access the bus & hog it for the other processors)... And then the vbl IRQ will start the 68K again, and after irq is done & exited, the 68K will be running again doing the "bra mainloop" instruction, doing another mainloop & shutting down afterwards...

 

That is the most optimal use of the 68K, stop it

 

But i mean this is not nessesary unless you intend to squeze out all dropps of jaguar power, you can to allot by using it & doing gpu calcs in paralell...

 

 

I will quote part of the "Jaguar Hints & tipps" project I planned to do ages ago... summing up usefull knowledge I found one way or another.. (never got to finish that project...)

Anyhow here are quotes from some docs i found (dont know whom it was, but its still true):

 

--------

There is a phrase that I ahve been trying to instill into the developer support people:

" If you are doing it in the 68000, you are doing it wrong".

 

In general there is little to be gained in trying to keep the 68k working in parallel with the Blitter and GPU rendering, because the bus is simply not free for the 68k to do anything. The only time that using the 68k can be a performance win is when Blitter is idle and the GPU is not on the bus. This is, in general rare.

-------

 

or quote from Leonard Tramiel:

"The best thing that can be done with the 68k for overall system performance is to execute a halt instruction."

-------

 

 

I understand this and it is consistent with the atari docs on the different cpu bus priorities.. But i mean in the beginning even rebellion had the same "68K parallell with gpu&blitter" thoughts (cf AvP beta source).. but one might assume that they had to rethink untill the final version of avp (or perhapps they did not..?)

 

Ahh well... you have been adviced

cheers

/Symmetry of TNG

Cool! =)

 

I have no idea how it actually works, but I can't imagine it is what I assume "raytracing" to be (ie allot of vector algebra, crossproducts,dotproducts, n stuff) ...since i assume that code to be bigger than 836 bytes

there must be some simplification involved... or?

 

Is that 3 shaded spheres ? ...or just one? (the green one?) ..i mean regarding fixpoint, why does the red&blue look smoother shaded than the greenone?... wouldnt the math be the same?...

are there some Z values involved?..and how do you calculate the shadevalues?

 

Just qurious

 

is it .8 or .16 fixpoint? ... (or signed 7.8 or something)....

And sorry for beeing "nosy" but Im just qurious if you use vectormath or not.. and if that is the precision you get with the fixpoint?...

 

..Its nice work Orion! =)

 

 

 

some thoughts:

-Could the DSP do half of the screen? ... (ie ~2 faster... not counting the 16bit bus to dsp, hence the "~")

 

-Do you storew pixels to screen space with external stores?

A good idea would be to let the gpu build, say 1 scanline of the screen in GPU memory, and then Phraseblitt a hole scanline to screenspace... killing all external stores!

Combine this with the 1st point.. letting the dsp do same thing but other half of screen...

 

-Another gpu thingy is to do 2pixels at the same time... (dont exactly know how the inner loop looks but..) usually you can optimize it and interleave 2 similar calculations, and build 2 pixels at the same time, and make 1 store to GPU memory (storing two 16bit pixels at the same time).. and then after a scanline do the phrblitt to screen...

(this might increase part of the codesize by *2.. (&register usage) since you have to do same thing twice... and you might have to do special "pre-loop" setups.. to get it working... (common on the falcons dsp) but you kill all waitstates that you might have in the code.. and half the loopcount.... making use of true RISC power.. (1tick/instruction)

 

>I will try to start making some more useful stuff from now ^^)

 

Ohh... it was that then

But this could be "usefull!" ... ...in my eyes it is defenitely NOT a waste of time anyway..

 

cheers

what... do you mean that you could not use a "jr" instruction in an IRQ or what?

 

It should work....

 

hmm.. please elaborate on this....

Are the code to big or to secret to post here or could you post, working relative code (outside irq), nonworking code(inside irq), and working absolute code?

 

Would just be interesting to se...

 

regards

/Sym

Nice demo Orion! =) ..I always liked those "SplineY-balls" =) (perhapps its not splines but trigonometry based?, but anyway)

 

Any luck on finding that other half of the ball? =)

 

keep up the good work!

regards

/Sym

>oh, now I see why you asked about scaled bitmaps

 

Well ...I have a dream... =) ...or had a dream... years ago... but It got stuck on the same thing I get stuck on now... that is OL building... I admit it! I suck at ObjectLists!.. =)

 

scaled transparent bitmaps + my 3D engine/rotator can ONLY mean one thing

But it dint work since the rmw objects werent scaled and the additions "Carried over" creating black squares instead of a soft toned edge.... so that code got stuck in the archive...

 

 

I know that I soon have to take the bull by its horn and do a kick@$$ spriteengine (gpu+blitter managed, with scaled bitmaps that are correctly clipped to screen space and sortable in different orders)...

Since I have more dreams that depend on such a thing....

 

 

>but I guess this is what the -glass flag of tga2cry gives (not sure however)

 

as i understood it it makes the gfx signed ...the 2 colour vectors and the intensity vector... ..

Though ...Im not sure if it just makes it relative to $80 (iirc "eor #$80, that is the intensity) or if it takes care of the color vectors aswell...

 

 

>For the moves, it uses the pseudo random number generator I have posted in an other thread...

 

Well it lokked like Brownian motion to me (ie exactly that, random particle motion)

 

The Jagscene soon have enough demo effects to make a MEGA demo.. yeeeyyy!

 

cheers

/Sym

Nice demo man! =)

 

And NO the scroll is not to BIG =) ...but it lacks something... (besides a greet ..it should have had a sinus shaped Y-scale zoom on it and the nostalgia would have been complete..

 

No sincerely.. a nice demo!... Im glad and inspiered by the fact that some small demos are beeing published for the jag!...

 

nice, cool work!

 

cheers!

/Symmetry of TNG

Nice Blobs demo SebRmv !!! =)

 

are that scaled bitmaps? ..

 

..and a Brownian motion simulation or what?

 

 

Well for the blitter i understood it, yes intensity is a signed 7bit value... and as i understood it so are the cry colours.. ie 1 cry value are composed of two 3bit signed colour components and one signed 7bit intensity component.. (ie s3s3s7 (s=signed, #of bits)).

With the blitter properly set up additions will saturate to produce a binary value of %0111011101111111 for positive values.

 

I hope to god the OP does the same!... and SebRmv, if that is OP bitmap objects with just the rmw bit set (and the data all opsitive values) then it would apear so... (i must have made some mistake in the test code i made back when i experimented with it... Im pritty sure i know what... since the BG also needs to be signed... which it wasnt... and perhapps i cant use the bitmaps i choose for the blobs...)

 

..This is done with the "-glass" parameter in the tga2cry program atari created.. ( i know that... now)...

 

 

Will have to reopen my old x-files and finish that code ;P

 

regards

/Sym of TNG

Hi!

Not 100% sure about this, but thought to talk a bit about it anyway..:

 

I tried to do "flare effects" with the RMW flag quite some time ago, but i never got it to work properly... ie not as one would want it to... ie for example have a texture bitmap & add 3 light objects intop of it and it would saturate into a bright picture (with strange colors I know, due to CRY mode, but anyway)... Instead I found it doing "carry additions" so it never went to FF in intensity but to 00... (???) ...

 

I hope this is due to a mistake i made and not due to limitations in the OP...

But the OP is simpler than the blitter (thats for sure) and the blitter can do this verry nicely... (cf. gouroud shaded texturemapping on the atari 3D examples).

 

Im not sure if the OP just ADDs the values together... and carry if it has to... ie it would have to be FF/3 in intensity if 3 objects were to be added.. or it would saturate... this makes it kind of useless to have since you never know how menu objects that will overlap... (in general)..

 

BUT I hope I am wrong!... and if noone overproves me here I will test it again at some point and revist the code based on todays knowledge...

 

I also know that Doom uses this to do the "hit=red flash" effect... they set up a 1phrase "big" object (that is set to repeat=hole screen same color) ...and they just change this one single phrase, and the hole screen is changed in various red tones... (and al the colours in the bitmaps below get a red tone).. (this is what makes me beleive I have some errors in my code!.. it should work!)...

 

Offcourse, also AvP uses similar thing for the HUD.... hmm.. but now when i think of it I think they used the blitters "RMW" function... to add the green tone...

 

(Also be ware of the rmw object bug!)...

 

regards

/Symmetry of TNG