• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Sega hire us, we can make your AGES games even worse, just as you like it

Panajev2001a

GAF's Pleasant Genius
Long time no update.

pics_0001.jpg


This is a screen-grab of the Z-buffer with values clamped/capped using 8 bits of precision, so it is not the full 24 bits Z-buffer which would be something like:

pics_0003.jpg


pics_0002.jpg


Why is texturing all wrong ?

Code:
	int u [3] = {0, 256, 256};
		
int v [3] = {0, 0, 256};

I am not importing the UV data from any mapper and I am not doing perspective corretion for textures either...

We started doing this as we wanted to separate the task in steps, now it is time to add the missing steps like proper UV/ST mapping and perspective corrected texturing.

Finally got the time to do a simple 3D camera with (from Object Space to Clip Space is my work, from Normalized Device Co-ordinates to Device Coordinates I am using Sparky's code ;) [playstation2-linux.com] ).

I have, as I wanted, my nice IGGS_frustum call... (lookAt is already in place) ahem... ripoff ;)

I have to add support for ahem... IGGS_perspective, pen and paper and I should be ready to go mapping FOV, height, width, etc... to the Top, Bottom, Left and Right clipping planes.


All right... back to my DSP homework sigh :(... I hate that class...
 

Panajev2001a

GAF's Pleasant Genius
It is funny how many hours went from the last pics psoted to now and yet the only different thing noticeable in the shots is that we now have perspective projection lol.

There is more under the hood though :).
 

slayn

needs to show more effort.
homework? since when are you in school? =P

also, just thought u might be interested to know that for my senior group project, we'll be taking my gba block puzzle of old, and turning it into a full game. Though we have to start from scratch rather than just yoinking what we had done as IGGS :(

perhaps a *little* copy and paste won't hurt though ;P

theres gonna be 8 of us working for the year on it so I'll have to remember to show you the final results ^_^

edit: also, is this done with openGL, or is it just that graphics in general is so similar, that since openGL is all I know that everythign looks like openGL to me?
 

Panajev2001a

GAF's Pleasant Genius
slayn said:
homework? since when are you in school? =P

also, just thought u might be interested to know that for my senior group project, we'll be taking my gba block puzzle of old, and turning it into a full game. Though we have to start from scratch rather than just yoinking what we had done as IGGS :(

Cool, at least you are doing something fun.

My senior porject partner and I were designing on ASIC a single port SRAM (4096 words, each word being 32 bits), 32 bit data bus x2 (parallel input and output pins pairs), 12 bits address bus, x bits control (forgot lol).

Professor jut updated us with a nice new info: you only have 36 pins. FUCK.

Is it going to be a full GBA game ? Or will it be a PC game ?

Well, we did not research serialized RAM... well RAMBUS here I come ;).

perhaps a *little* copy and paste won't hurt though ;P

Np, as long as you can put IGGS somewhere ;).

theres gonna be 8 of us working for the year on it so I'll have to remember to show you the final results ^_^

Darn... sigh... and you prlly have several artists too :(... a team of 8 people working closely... buaaaaahhh... :( :(

Sorry, jealousy attack is over :).

edit: also, is this done with openGL, or is it just that graphics in general is so similar, that since openGL is all I know that everythign looks like openGL to me?

No, this is not done with OpenGL although I am trying to mimick its interface a bit oin the way you program for this engine translating, rotating... you always start from an Identity matrix and you have a matrix stack).

This is done leveraging SPS2, a low level library for PlayStation 2 Linux which exposes the Hardware very well (and we are using something called SPS2Utility to start the GS up: configuration of the GS registers realted to the Z-buffer type, screen type, frame-buffer size, etc...): we get to play with the DMA controller (the GBA one was a joke in comparison ;), the PlayStation 2 lives around the DMA Controller), the VIFs (Vector Unit interfaces), the GIF (Graphics Synthesizer Interface), etc...

SPS2 is not an engine, SPS2 most of all exposes the harware units (except the I/O CPU and the SPU2, those are governed by PlayStation 2 Linux) and then it is up to you to make them do something useful.

It is very similar to how people work on the TOOL as far as I hear in regards to system abstraction: http://playstation2-linux.com, for more :).

Running things is no easy, but running them fast is hard: there is a steep learning curve, especially when you start, but it is not impossible to program for.

Example: we went from a DMA call for every geometric object upload to the VUs and for the upload of textures, etc... to a long and nested DMA chain started by a single DMA call.

One thing that will pis you off is the fact that SPS2 can only allocate 4 KB of non-swappable (we do not want the Linux kernel to slow us down, we want to keep it from stealing cycles to our application... cycles we want to control ;)) and physically contiguous (the DMA Controller does not understand virtual addresses which Linux uses) memory.

If you allocate 2 MB of memory you cannot pretend that pStart and pEnd are physically contiguous even tough they are virtually contiguous.

So you have to do something called "stitching": setting DMA tags properly to jump from contiguous block to contiguous block.
 

Fafalada

Fafracer forever
Panajev said:
Finally got the time to do a simple 3D camera with (from Object Space to Clip Space is my work, from Normalized Device Co-ordinates to Device Coordinates
Bah wuss, using clipspace. Real men, I mean, PSP devs, do their clipping in Object space! :p

If you allocate 2 MB of memory you cannot pretend that pStart and pEnd are physically contiguous even tough they are virtually contiguous.
In a way, you should be thankfull for that - allocating long dynamic DMA lists in a bunch of smaller blocks is the RIGht way to do things, the only time a massive linear allocation is the way to go is when you have a static list that has a fixed length.

Of course - this only pertains to DMA chains themselves, I would be crying my eyes out if I couldn't allocate actual texture and geometry data in arbitrarily large blocks. :(
 

ourumov

Member
Just got up...And I see Pana creating hype ;)

Hopefully texturing will improve when we move to a different file format that allows us to manage better texture coordinates.
A sprite class has been developed as well and soon will follow a particle class.
We also achieved some kind of multi-texturing which for now is on schedule for a better implementation.
 
Top Bottom