The project is in hiatus due to other programming tasks.
In the meanwhile I've put all sources on GitHub, maybe my efforts will be of any help.

https://github.com/apiraino/psx_tapper

I also tried to write a tutorial to summarize the steps to get started, hoping to save some time to newcomers ...

Hello,

I'm trying to figure out this: let's say I have a sprite moving. When it goes a certain coordinate it should gradually disappear behind the backgroud.
Imagine a sprite representing the hero entering a house. I'd like this sprite to get lower drawing priority as it moves through the door: I'd ...

Here are some updates.

I've reworked a lot of things:
- fully converted the game in interlaced 512x480
- converted all the sprites in 8bit TIM
- added the logic to switch screens (intro, gameplay, high scores)
- implemented 90% of the gameplay

TODO:
- when the customer reaches the barman there's ...

I don't have much time currently but I won't let this project die.
Here are some screenshots of the current progress.


I love the font, it's so "Playstation" :)
Great overall graphics.

I should post a current progress too for the Tapper clone. I'm a bit stuck in a programming-related thing, but ...

It's still much to difficult to control. I suggest using analog or just use a float like I was.

Too difficult because of the movement resolution? I'm already using float, if it's too fast, drop down the MOVE_OFFSET.
I admit I didn't test in on hardware yet; you did test on hardware, right?

Also ...

ok re-uploaded the attachment.

One thing I've noticed is that this tool doesn't help very much in those cases where you don't need the [x,y] center of your sprite.
A sprite can be on any size and shape, so now I'm also showing the edges of the crosshair but a better tool could be if it could show ...

I use CCPSX because it makes me feel more like a Sony developer from back in the day, though using the latest GCC MIPS compiler would make some things in the code a lot easier :P
I agree. I would use a modern GCC too in order to 1) be able to compile from Linux 2) have better error reporting and 3 ...

Here is a version that implements your suggestions.
Also, now the coordinates box is movable in case one needs to go exactly there with the crosshair.

Bug: since the crosshair and the coordinates box move in float steps, depending on the offset choosen you may not be able to get exactly of the edge ...

I've found a reference for Psy-Q Makefiles here (pag. 197):
http://koti.kapsi.fi/~antime/sega/files/SATMAN.pdf

The document it's for the Sega Saturn platform but the company is always SN Systems...

Again, your MAKEFILE is wrong. It must have the extension '.MAK', and you can't use comments (#) like this 'CFLAGS=-Wall #-o2'. Stop uploading stuff that you think is working.
The reason is that I don't use psymake at all. I use GNU make which (imo) is more flexible. Again, I should have mentioned ...

There you go (PSXLIB removed).

I was thinking of making something like this, but I just could not be bothered. I can't seem to compile it though, firstly because there is no such file as 'main.c' as per your MAKEFILE :P
Sorry, it was a bit late so I rushed things a bit. I didn't mention that I used Orion_'s wrapper, his System ...

Hi,

it's boring to be forced to do many builds just to fine tune the pixel position of a sprite so I couln't think of anything else than putting together a small tool to help me finding the [X,Y] coordinates on screen.

This tool can be activated/deactivated at compile time with -DPIXFINDER and ...

@tommy, thanks for your reply, actually my quesiton was bad formed. What I meant is that if I declare a GsSPRITE spr I have an object already usable while if I declare GsSPRITE *spr I have a pointer that needs all the usual C treatment (malloc3(), free3(), ....).

At first this wasn't clear to me as ...

I noticed another interesting thing: apparently GsIMAGE and GsSPRITE structs are already allocated when the application starts and they are *never* deallocated.
If I declare a global Gs* object and I print their address right at the beginning of the main() they are not null.

Should I be concerned ...

Thanks for the explainations :-)

tlrmcknz wrote:Running Windows XP 32bit, I needed to add "REGEDIT4" at the top of the reg file for it to be recognized.

That header is likely to enforce compatibility with RegEdit v4. I have v5.1 on XP/SP3 updated.
Possibly you have a older version of XP?

Yagotzirck wrote:I wondered about the same thing a while ago: http://www.psxdev.net/forum/viewtopic.php?f=51&t=391
Though, nobody could give an exhaustive explanation

Thanks for pointing me to your thread, it was interesting nonetheless

The reason why I wanted to do this repack is because I think that the overabundance of folders and duplicates in the full SDK will seriously confuse beginners, so I thought it would be nice to make a repacked version of the SDK that is smaller, less confusing, and includes easy to understand ...

I've understood how to match the texture page value you're using (8,9,10,...), it's also indicated in TIMTOOL.

http://www.psxdev.net/forum/download/file.php?id=329

In this image one can see that a TIM file with the left upper edge at [0,512] (marker 1 and 3) has texture page = 512 / 64 = 8 ...