LibGBA naming convention

[Legolas]

The library for gba coding I released was a bit raw, so I have made a new (and more complete) port, translating libgba to pascal, and packaging it for freepascal. Now I have a little dilemma: should I follow pascal naming convention (making everything more understandable for pascal people) or should I let original libgba names (making easyer to understand existing c tutorials and code for gba)?
EG.: now I have code like
// original libGBA naming convention
type bg_scroll = record
x: u16;
y: u16;
end;
...
function BG_PALETTE(m: integer): integer;

but maybe should be nicer (and more readable)
// pascal naming convention
type TBgScroll = record
x: u16;
y: u16;
end;
...
function BgPalette(m: integer): integer;


Any suggestion will be very appreciated :wink:

[grudzio]

I think you should stick to the pascal naming convention. I don't think it will casue problems with C to pascal conversion and it would be consistent with other freepascal libraries. It is just a matter of remembering that C type names will be prefixed with 'T', pointers to them with 'P' and no underscores. And last (but not least :)) I think that
type TBgScroll = record
x: u16;
y: u16;
end;
...
function BgPalette(m: integer): integer;


is prettier than
type bg_scroll = record
x: u16;
y: u16;
end;
...
function BG_PALETTE(m: integer): integer;

[K4Z]

If it were a port for own use only, I'd personally keep the original convention; makes tranlsating and finding bugs heaps easier.

Though if you don't mind too much, it would be better, and look nicer overall in a pascal convention.

[WILL]

I'd say go with Pascal. Odds are it'll anyone using it will break away from the C-based tutorials and conventions rather soon anyways. :)

Just don't pooch the capitalizations, if you're gonna use 'em. I find that really fustrating to work with. It also makes the library look sloppy imo. :p

[technomage]

I think normal "JEDI" convention is to keep the origional definitions but to declare Pascal style ones



type bg_scroll = record
x: u16;
y: u16;
end;
TBGScroll = bg_scroll;
PBGScroll = ^TBGScroll;



Functions are declared in normal Pascal style though.

[Legolas]

I think normal "JEDI" convention is to keep the origional definitions but to declare Pascal style ones



type bg_scroll = record
x: u16;
y: u16;
end;
TBGScroll = bg_scroll;
PBGScroll = ^TBGScroll;



Functions are declared in normal Pascal style though.
Uhm... yes, this could be a good solution :)

[dmantione]

There are two groups of Pascal coders, people_that_underscore_their_identifiers and PeopleThatIniCapsTheirIdentifiers. There is no preferred convention for Free Pascal, as long as a single unit is reasonably uniform.

What we do not really appreciate is ALL_UPPERCASE identifiers. If there is a need to highlight parts of the code there exists syntax highlighting. Lastly, please do not invent your own typenames. While names like u8, s8, u16 are not necessarily a bad idea, people do not like it if a type in one unit is named differently than the same type in another unit.

Be care of variables that contain a memory address, they should not be converted to cardinal or u32, but to a pointer, or if an integer type makes more sense, ptruint.

[Legolas]

There are two groups of Pascal coders, people_that_underscore_their_identifiers and PeopleThatIniCapsTheirIdentifiers. There is no preferred convention for Free Pascal, as long as a single unit is reasonably uniform.


IAmThisKindOfPascalCoder :mrgreen:


What we do not really appreciate is ALL_UPPERCASE identifiers. If there is a need to highlight parts of the code there exists syntax highlighting.

In fact I hate this kind of highlighting too. I have let all uppercase for const values only (that seems to me "pascalish" enough)


Lastly, please do not invent your own typenames. While names like u8, s8, u16 are not necessarily a bad idea, people do not like it if a type in one unit is named differently than the same type in another unit.
Be care of variables that contain a memory address, they should not be converted to cardinal or u32, but to a pointer, or if an integer type makes more sense, ptruint.

These typenames are let to be more consistent with existing documentation about gba programming. According to memory region where a variable is written, I need a different data type to write, in order to prevent strange behaviours. However I have tryied to make a consistent data types usage in different units.

I'm not sure I have understood the stuff about memory locations. EG. this one:

VideoBuffer : ^u16 = pointer($6000000);

is the only way I have found to write u16 data starting from memory address $6000000. :think:

[dmantione]

Lastly, please do not invent your own typenames. While names like u8, s8, u16 are not necessarily a bad idea, people do not like it if a type in one unit is named differently than the same type in another unit.
Be care of variables that contain a memory address, they should not be converted to cardinal or u32, but to a pointer, or if an integer type makes more sense, ptruint.

These typenames are let to be more consistent with existing documentation about gba programming. According to memory region where a variable is written, I need a different data type to write, in order to prevent strange behaviours. However I have tryied to make a consistent data types usage in different units.


Well, I don't want to force anything on you, so please do what you feel is right. However, please look at the big picture. For example in Pasjpeg, as 32 bit signed integer is called int32. In Paszlib it was called sint32, etc. Of course nothing is wrong with a simple longint.

I'm going to kill all of this in the FPC sources, because this introduces nothing but chaos. Paszlib is already done, Pasjpeg is on the todo list.



I'm not sure I have understood the stuff about memory locations. EG. this one:

VideoBuffer : ^u16 = pointer($6000000);

is the only way I have found to write u16 data starting from memory address $6000000. :think:

This is completely acceptable. I meant you should avoid code like this:

var video_location:cardinal;

begin
video_location:=$6000000;


Better is:

var video_location:ptruint;

begin
video_location:=$6000000;


However, a pointer is what you should aim for:

var video_location:pointer;

begin
video_location:=pointer($6000000);


Generally, I think we should enable the absolute variables for the GBA. I.e. the compiler supports this:

var videobuffer:array[0..$ffff] of byte absolute $6000000;

This construction is accepted for Dos only, because Dos was until now the only OS where this made sense. However, it would be a very good idea to enable it for the GBA as well.

[Legolas]

Well, I don't want to force anything on you, so please do what you feel is right. However, please look at the big picture. For example in Pasjpeg, as 32 bit signed integer is called int32. In Paszlib it was called sint32, etc. Of course nothing is wrong with a simple longint.

I'm going to kill all of this in the FPC sources, because this introduces nothing but chaos. Paszlib is already done, Pasjpeg is on the todo list.

No problemo! I can remove it from library, letting those data types to the private use, if someone is comfortable with it.


Generally, I think we should enable the absolute variables for the GBA. I.e. the compiler supports this:

var videobuffer:array[0..$ffff] of byte absolute $6000000;

This construction is accepted for Dos only, because Dos was until now the only OS where this made sense. However, it would be a very good idea to enable it for the GBA as well.
Yes, I requested it some times ago. It is cleaner than assigning pointer to consts here and there too :)
BTW, do you think that activating absolute for gba could be a feasible task for me? :think:

[dmantione]

BTW, do you think that activating absolute for gba could be a feasible task for me? :think:

It is now activated for GBA.

[Legolas]

BTW, do you think that activating absolute for gba could be a feasible task for me? :think:

It is now activated for GBA.

Nice (and fast) :D
BTW I have replaced all custom types with standard ones.
A doubt I had since a long time: gba libs use a lot of volatile variables. AFAIK volatile tells to compiler that the variable should not be optimized, because its value could change autonomously (eg. by hardware input). Up to now, I have tryed to emulate it by switching optimization off, but I don't know if this is the right way to make the job. :scratch:

[dmantione]

You can simply ignore it. Volatile is not necessary for FPC, the compiler doesn't do that kind of optimizations yet.