Pixfinder

[jman]

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 will show a crossbar and will FntPrint() the crossbar coordinates, simple as that.

It can be configured on how many pixels to move and whether to FntFlush immediately or not (useful if there is other debug FntPrint).

Usage example:
ccpsx -DPIXFINDER pixfinder.obj main.c -o main.cpe

It should be tested a bit and it can surely be improved. Namely it crashes with the NO$PSX (I will investigate).

If something's not clear let me know.

[Administrator]

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

Working further, I found more errors.
To start off, all the names were longer than 8 chars. So, I renamed them all to 'pxfinder'.

First error is that your MAKEFILE is wrong. It should be:

Code: Select all

# -----------------------------------------
#       PlayStation 1 Psy-Q Makefile
# Sony Computer Entertainment Europe (SCEE)
# -----------------------------------------

all:
	del pxfinder.map
	del pxfinder.sym
	del pxfinder.exe
	del pxfinder.cpe
	cls

	#ccpsx -c -g pxfinder.c
	#psylink /m @pxfinder.lnk,pxfinder.cpe,pxfinder.sym,pxfinder.map
	#cpe2x /ce pxfinder.cpe

	ccpsx -Xm -Xo$80010000 pxfinder.c pxfinder.obj -opxfinder.cpe,pxfinder.sym,pxfinder.map
	cpe2x /ce pxfinder.cpe

Second error is that there are obvious mistakes in your code:

Code: Select all

pixfinder.c:2: System.h: No such file or directory
pixfinder.c:134: warning: #warning Crash with NO$PSX

After fixing those mistakes and removing the unknown header file 'System.h', it throws a shit ton of errors...

Code: Select all

...
pixfinder.c:100: `PADLleft' undeclared (first use in this function)
pixfinder.c:101: `PADLright' undeclared (first use in this function)
pixfinder.c: In function `__pixfinder_Tim_Load':
pixfinder.c:106: `RECT' undeclared (first use in this function)
pixfinder.c:106: parse error before `rect'
pixfinder.c:107: `GsIMAGE' undeclared (first use in this function)
pixfinder.c:107: `image' undeclared (first use in this function)
pixfinder.c:112: `u_long' undeclared (first use in this function)
pixfinder.c:112: parse error before `)'
pixfinder.c:114: `rect' undeclared (first use in this function)
pixfinder.c: In function `__pixfinder_initCursor':
pixfinder.c:139: request for member `attribute' in something not a structure or
union
pixfinder.c:140: request for member `x' in something not a structure or union
pixfinder.c:141: request for member `y' in something not a structure or union
pixfinder.c:142: request for member `w' in something not a structure or union
pixfinder.c:143: request for member `h' in something not a structure or union
pixfinder.c:146: request for member `tpage' in something not a structure or unio
n
pixfinder.c:149: request for member `r' in something not a structure or union
pixfinder.c:149: request for member `g' in something not a structure or union
pixfinder.c:149: request for member `b' in something not a structure or union
pixfinder.c:152: request for member `u' in something not a structure or union
pixfinder.c:153: request for member `v' in something not a structure or union
pixfinder.c:156: request for member `cx' in something not a structure or union
pixfinder.c:157: request for member `cy' in something not a structure or union
pixfinder.c:160: request for member `mx' in something not a structure or union
pixfinder.c:161: request for member `my' in something not a structure or union
pixfinder.c:162: request for member `scalex' in something not a structure or uni
on
pixfinder.c:162: `ONE' undeclared (first use in this function)
pixfinder.c:163: request for member `scaley' in something not a structure or uni
on
pixfinder.c:164: request for member `rotate' in something not a structure or uni
on
pixfinder.c: At top level:
pixfinder.c:167: parse error before `ot'
pixfinder.c: In function `__pixfinder_drawCursor':
pixfinder.c:169: `ot' undeclared (first use in this function)
pixfinder.c: In function `__pixfinder_drawCoords':
pixfinder.c:174: request for member `x' in something not a structure or union
pixfinder.c:174: request for member `y' in something not a structure or union
pixfinder.c: At top level:
pixfinder.c:187: parse error before `ot'
pixfinder.c: In function `pixfinder_draw':
pixfinder.c:191: `ot' undeclared (first use in this function)
pixfinder.c:192: `f' undeclared (first use in this function)
Bad return code - make aborted

After adding in these useful libraries: ...

Code: Select all

#include <sys/types.h>
#include <libetc.h>
#include <libgte.h>
#include <libgpu.h>
#include <libgs.h>

I got these errors:

Code: Select all

C:\psyq\bin\ccpsx.EXE -Xm -Xo$80010000 pixfinder.c pixfinder.obj -opixfinder.cpe
,pixfinder.sym,pixfinder.map
pixfinder.c:18: `OT_LENGTH' undeclared here (not in a function)
pixfinder.c:18: size of array `myOT_TAG' has non-integer type
pixfinder.c:19: `PACKET_SIZE' undeclared here (not in a function)
pixfinder.c:19: size of array `GPUPacketArea' has non-integer type
pixfinder.c: In function `main':
pixfinder.c:29: `MODE_PAL' undeclared (first use in this function)
pixfinder.c:29: (Each undeclared identifier is reported only once
pixfinder.c:29: for each function it appears in.)
pixfinder.c:34: `OT_LENGTH' undeclared (first use in this function)
pixfinder.c:47: `Pad1Start' undeclared (first use in this function)
Bad return code - make aborted

After editing and adding and editing a few lines, I managed to get it to compile. Download the code attached below based off of 'pixfinder_test.c'. All I get is a grey screen though whilst running it under PSXEven.

It makes me wonder. Did you code this for a PSX or a toaster????

[jman]

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.h is very helpful in easing how to build an application. Just don't delete System.o and you'll be fine.

If you don't like to have external "dependencies" other than the stock SDK, I can rework the sources (like you did) so it's not needed.

I've renamed files as per your suggestion and I've repackaged everything, now things should be clearer.
If anyone wants to build pxfinder itself I've also included the full Makefile.

To build the module: make pxfinder
To build a sample application: make main

To start off, all the names were longer than 8 chars. So, I renamed them all to 'pxfinder'.

Thanks, I always forget about this limitation.

It makes me wonder. Did you code this for a PSX or a toaster???? :!:

Yes, this one.
It's good to have feedback.

[jman]

There you go (PSXLIB removed).

[Administrator]

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.

Also, it can't be just 'make'. It has to be 'psymake' or 'psylink' (should you have a linker file).
If I type 'make pxfinder', I get:

Code: Select all

MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
ccpsx -Wall -o2 -I\. -Xo$80100000 -c pxfinder.c

since I have Borland C setup.

So, fixing your MAKEFILE again with this code:

Code: Select all

# -----------------------------------------
#       PlayStation 1 Psy-Q Makefile
# Sony Computer Entertainment Europe (SCEE)
# -----------------------------------------

all:
	del *.map
	del *.sym
	del *.exe
	del *.cpe
	cls

	ccpsx -Xm -Xo$80010000 -DPXFINDER main.c pxfinder.c -omain.cpe,main.sym,main.map
	cpe2x /ce main.cpe

Solved the compile problems again

Anyway, some problems with the actual logic is that the cursor moves much to quick. I fixed that, but as for the other problems (the cross hair isn't aligned in the center, the cursor could can move indefinitely outside of the room...), I can't be bothered. Download the working version below and just type 'psymake' to compile.

That toaster seems pretty poor at doing it's job.

[jman]

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 this too.

Solved the compile problems again :)

Thanks!
However, the pxfinder module is intended to be used as is, it should not be needed to compile it everytime within your project. I see it more like using like the MMGMNEW.OBJ object: you link it and you have available its functions.

the cross hair isn't aligned in the center, the cursor could can move indefinitely outside of the room

Ok, I'll work on these too, thanks for taking the time to test it.

[Administrator]

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 this too.

Ah, that would make sense
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

Thanks!
However, the pxfinder module is intended to be used as is, it should not be needed to compile it everytime within your project. I see it more like using like the MMGMNEW.OBJ object: you link it and you have available its functions.

Yeah, but first it must be compiled and working decently.

Ok, I'll work on these too, thanks for taking the time to test it.

No problem.

[jman]

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 of the screen. A better version could implement a dynamic resolution movement.

Usage:
DPAD to move the crosshair
L1/L2, R1/r2 to move the coordinates box

Included both GNU and Psymake makefiles to make everyone happy :-)

I will test it on real hardware when I have the chance.

EDIT: updated attachment

[jman]

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) get rid of some awkarwd C89 limitations (variable declaration only on top of a code block) but I'm concerned about the resulting executable size. What do you think?

[Administrator]

Use shorts where needed, unsigned and signed also where possible and good structured C code for high assembler/binary optimisation by the compiler. Your upload (20140513_pixfinder.zip) from above is also missing.

[jman]

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 on screen your sprite file so you have a real idea of how it will look. pxfinder could manage to load your TIM file, isolate the sprite coordinate and show on screen the real sprite that you want to place. That's an idea for improvement.

[Administrator]

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

[jman]

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 I thought about using the analog pad but I would loose compatibility with the first version pad (or I should not be concerned about that?).

[Administrator]

I have not tested it on real hardware yet. You don't need to worry about it so long as in your code you are constantly checking for the analog and digital modes and are switching to them accordingly.