GUI Colours - More Possibilities

Deji · 15-07-2010 04:55

It's still a work in progress as of now, but I'd like to gesture anyone interested to my topic on HUD Colours.

I've been busy trying to crack down on getting each HUD Colour different and think I've found a solution, as described here.

Just thought it might be of interest to people here. I've been spending a while figuring this out and it's all coming together now. I've also found out loads more about how GUI is done in SA and some other tidbits about ASM in IDA.. Hopefully soon I'll be able to actually use that information.

5AM... Now is the time for me to sleep.

listener · 15-07-2010 06:41

This was reply to the "screen deformation" topic.

0x858B8C - is a constant, not a variable.
x86 FPU can't load immediate values, so, most of a floating point constants stored in the .rdata segment.

I'm not so sure about sub_719610. It definitely change font parameter, but I don't know yet, which parameter it changes. This part more complete in the IV/EfLC bases, and I will copy info to the SA/VC/LCS bases.

Also, in the IV, we have real opcode/native names. Maybe, one day, someone can map SA opcodes to the real names, e.g.

016C=5,restart_if_wasted_at %1d% %2d% %3d% angle %4d% town_number %5h% ; => ADD_HOSPITAL_RESTART
016D=5,restart_if_busted_at %1d% %2d% %3d% angle %4d% town_number %5h% ; => ADD_POLICE_RESTART
09AF=4,set_trip_skip %1d% %2d% %3d% angle %4d% ; versionB => SET_UP_TRIP_SKIP_AFTER_MISSION
09E0=5,trip_skip %1d% %2d% %3d% angle %4d% when_in_car %5d%  ; => SET_UP_TRIP_SKIP_FOR_SPECIFIC_VEHICLE
0A35=5,trip_skip %1d% %2d% %3d% angle %4d% when_in_car %5d%   ; => SET_UP_TRIP_SKIP_FOR_VEHICLE_FINISHED_BY_SCRIPT

and so on.

PS. Did you see http://public.sannybuilder.com/sources/ … 090822.rar ?

Deji · 15-07-2010 15:19

I could do that with the Opcode Database... More specifically, make a new version of .ini's and opcodes.txt files altogether, so that people who still need to use the old .ini to compile their scripts still can and use updated definitions. I didn't want to confuse people by changing all the names of things, making it harder to search through Sanny's Opcode Search.

No.. OpenSanAndreas? That sounds very big and complex smile I'm only just learning C (decided to switch from learning C++) so I only understand parts of the source. I was going to learn ASM, just because of the ability to execute it in San Andreas, but I might save that for later. Still, looking through IDA gives me a basic idea of how it all works.

NTAuthority · 19-07-2010 18:45

listener wrote:

Also, in the IV, we have real opcode/native names. Maybe, one day, someone can map SA opcodes to the real names, e.g.
*snip*
and so on.

I once started on making a list of command names for SA, but quit due to it being a large task. Starting at III might be a lot easier? Another things I have in my mind is a lot of information about the .sc source code format, both for III/VC, SA and a bit of IV -- I really ought to document my information on it someday.

For who's interested in these old ugly lists, see the two things posted on pastebin (made before I started looking through disassembly, though):

http://pastebin.com/p0Vi9QT1 - old list
http://pastebin.com/iSqbjygS - some advanced XML format with documentation built in

PS. Did you see http://public.sannybuilder.com/sources/ … 090822.rar ?

Ah, yes, OpenSA was another thing inspiring some 'likely never to be implemented idea' of mine -- something like header files for 'plugins' with normal 'real' functions but then having stuff mapped to the locations as seen in the compiled code... Also, I should really look more into internal code for IV, my main information is based on continuation of the SA IDB and III IDB found on public.sannybuilder.com and 'common knowledge'. tongue

Last edited by NTAuthority (19-07-2010 18:49)

Seemann · 19-07-2010 18:53

@NTAuthority - guess you know, but anyway
http://www.joncaruana.com/projects/point/scm_api.xml

an attempt of making a xml-based opcode list

NTAuthority · 19-07-2010 19:04

Seemann wrote:

@NTAuthority - guess you know, but anyway
http://www.joncaruana.com/projects/point/scm_api.xml
an attempt of making a xml-based opcode list

Yes, I knew about the Point implementation already -- that was one of the inspirations for my list, which was meant to eventually be used by a SA SC syntax compiler/IDE as 'fully-documented' file.

Deji · 19-07-2010 20:20

I can't quite see the aspiration to do these things manually. If you want any help on compiling anything, I'd be happy to help. What's more, I'd be happy to try using PHP to generate these things instead.

Most of the opcode database was built by a simple PHP script I wrote. It read each .ini line of the original sascm.ini and added the appropriate entry to the database. Eventually, what was also done was the "Games" entries. By scanning the files again, I could get the database to organize all opcodes by the games they work with.

See here. All opcodes (except the 201 conditional "not" opcodes) organized into their appropriate game category, no work involved. There is very little support for conditional nots database, but some more PHP could apply all the info of the normal opcodes to them.

I could probably have it output an xml file with a lot of the opcodes description, parameters etc. which could certainly give you a much better starting point than the current method... or wait until I'm finished documenting everything in the database... Don't underestimate how much I've been doing already.

I'm planning to add a new field to the database to give the native names of each opcode on it's information page. Maybe updated classes.db and such, for people who are into that.

Still, what are you actually tryna achieve with xml?

Here's a sneak look of the workings of my list smile

Last edited by Deji (19-07-2010 20:40)

Planepics · 31-07-2010 11:34

The main advantage of doing stuff manually is attention to details, like the list at GTAModding. Every opcode seems to be accounted and undocumented ones were discovered there.

SannyBuilder.com Forums

#1 15-07-2010 04:55

GUI Colours - More Possibilities

#2 15-07-2010 06:41

Re: GUI Colours - More Possibilities

#3 15-07-2010 15:19

Re: GUI Colours - More Possibilities

#4 19-07-2010 18:45

Re: GUI Colours - More Possibilities

#5 19-07-2010 18:53

Re: GUI Colours - More Possibilities

#6 19-07-2010 19:04

Re: GUI Colours - More Possibilities

#7 19-07-2010 20:20

Re: GUI Colours - More Possibilities

#8 31-07-2010 11:34

Re: GUI Colours - More Possibilities

Board footer