Menu
What's new
By:
Filters

porting pj64 to unix

G

gumleef

New member
if this is wildly offtopic or has been discussed previously, feel free to flame away...

i would love to see project64 running on [insert unix of choice]
i just grabbed the source, and will prolly take a more detailed look later tonight.

First of all, is it feasable to port away from windows?
If anyone has started porting, please dont hesitate to contact me. Otherwise i might start doing some porting myself - any help would be apreciated. initial work would be done on NetBSD (my OS of choice), but since i only have an nvidia card, i would move development onto linux.
 
Hacktarux

Hacktarux

Emulator Developer
Moderator
I have tried making a port of the Jabo RSP plug-in because i wanted to find a solution to get sound in mupen64 before starting to work on hle audio (which is a very time consuming work :) ). In my opinion this is the less windows specific part but i have many difficuties. Finally i get it working in interpreter mode which is very slow (understand not usable). The recompiler mode crashes but it is very hard to find why. It seems that this is because of minor differences between gcc compilers and visual c.

I think that porting pj64 is probably possible but it is very hard because it uses windows (or visual c) specific stuffs. Remember that even if you get positive results with the core, you will have to program a big part of the emulator : the gfx plug-in (There's no good open source gfx plug-in).

Good luck with it !!
 
Last edited:
OP
G

gumleef

New member
well, after taking an in depth look at the code, i feel that porting would not really be a port, but more of a total rewrite - something that i dont feel im quite up for. There is MS specific code in places where there really shouldnt be.... and to be quite honest, its some of the ugliest code ive ever looked at.

i think ill look elsewhere for a unix n64 emulator, but dagnabit, it will happen!
 
Glurak

Glurak

New member
gumleef said:
well, after taking an in depth look at the code, i feel that porting would not really be a port, but more of a total rewrite - something that i dont feel im quite up for. There is MS specific code in places where there really shouldnt be.... and to be quite honest, its some of the ugliest code ive ever looked at.

i think ill look elsewhere for a unix n64 emulator, but dagnabit, it will happen!
Click to expand...

well it's a stable and quite fast core so the code can't be that ugly ;)

and u ever heard about mupen64? I think it should be portable to native unix quite easy...

http://mupen64.emulation64.com/
 
Z

zilmar

Emulator Developer
Moderator
gumleef said:
well, after taking an in depth look at the code, i feel that porting would not really be a port, but more of a total rewrite - something that i dont feel im quite up for. There is MS specific code in places where there really shouldnt be.... and to be quite honest, its some of the ugliest code ive ever looked at.

i think ill look elsewhere for a unix n64 emulator, but dagnabit, it will happen!
Click to expand...

some stuff is really old .. and if I had written at the end of the life of the emu it might have been very different .. but what parts do you think should not have MS specific stuff ? what part do find the code ugly and hard to deal with ?
 
OP
G

gumleef

New member
ok, taking yet another look....

most of the (bigger) issues i have could be fixed. main thing (for me) is that any MS code seems ugly - hdlg hwnd hasdf all over the place, u cant see what ur trying to do, where ur gui code ends and the app code begins :)
also ive never found any gui code that was nicely readable, thats not anyones fault but the gui implementors... whoa offtopic

ill bite the bullet and perform an MSectomy on the code, and see whats left. hopefully the results are usable, and ill prolly post the source it if anyones interested.

i still believe that a port would be a total conversion, but what the hell, im not really that busy.

please do not percieve this as an attack on your coding style, most of what im saying is based on opinion not fact and its likely that im just used to the code layout i see in /usr/src ;-D
 
Jabo

Jabo

Emulator Developer
Moderator
I don't think the project ever had any intention of being ported easily, it's quite a complex project that is reliant on a great deal of different things in windows (direct3d, memory handling, user interface, etc). Unfortunately for people porting this, it led to a tightly integrated win32 application, doing otherwise for us during development provided no incentive given the amount of work. The actual source is quite clean, the style is quite enjoyable, if you dislike win32 code than that can make parts of the source base very confusing, which as you said, isn't anyone's fault. If you look at other open source windows emulators I think you will find similar problems. I think the large majority of the code in the open source project 64 should be easily portable.
 
OP
G

gumleef

New member
yes i have looked at other windows based emulators and their sources do also have tightly integrated win32 code.

The main beef i have (which i am fixing this very moment) is mixed case filenames, with spaces instead of underscores. Some of the #includes use uppercase and others lowercase for the same header! This would never have been seen as a problem with a case insensitive filesystem such as FAT32.
There is inconsistent useage of typedefs, eg some places use the typedef, other places dont. a quick search & replace could fix this. there are many oher things that could use a search & replace.

many other smaller things, such as using a windows version of a function instead of the posix version. this is not your faut, as MS does not document the posix functions, nor even acknowledge their existence, but MS does support a large part of the posix standard.

PS: have not looked at mupen64, but i will be sure to do that as soon as the sources are released. it does seem like what im after, as i would prolly use SDL also.
 
Hacktarux

Hacktarux

Emulator Developer
Moderator
A little tip: use sed !!!!!!!!!!!
It is a great tool for doing text search and replace. You can use it in your makefile. In my rsp plug-in port, it allow me to compile it without modifying the source.
Make also a header file with macros in order to use posix equivalent functions.

Note: The pj64 source code is the cleanest windows specific code i have ever seen. But i think Zilmar and Jabo have never coded on unix systems. This should explain why they use so many windows stuffs. For example they use all the time windows types: WORD, DWORD, BYTE, BOOL... an unix programmer never use them even when he programs a windows tool because he is always thinking about future portablity. It is not for criticizing them it is just a noting.
 
Z

zilmar

Emulator Developer
Moderator
Hacktarux said:
This should explain why they use so many windows stuffs. For example they use all the time windows types: WORD, DWORD, BYTE, BOOL...
Click to expand...

The main reason I use them is that I am use to them. Pj64 was my first real major C program I ever did, I also like them cause it is how they are used often on an x86 programming level. As I was dealing with asm it made life easier to understand and to keep track. Done a bit of unix programming but they allways seem to have something like typedef unsigned long DWORD; added so that I can still use that style in the environment.
 
You must log in or register to reply here.

Top