The current version does not have all those names.Falcury wrote:so I guess these names in types.h are not really correct:
Where does "color_3_turquoise" come from, for example?
The current version does not have all those names.Falcury wrote:so I guess these names in types.h are not really correct:
Looks like now it has a challenger... https://github.com/NagyD/SDLPoP/issues/66Falcury wrote:I suppose this should also (rarely) happen in the original game? If so, this has to be the most obscure bug that has been found in the game so far! Nice find!
That bug is quite subtle indeed!David wrote:From viewtopic.php?p=18158#p18158Looks like now it has a challenger... https://github.com/NagyD/SDLPoP/issues/66Falcury wrote:I suppose this should also (rarely) happen in the original game? If so, this has to be the most obscure bug that has been found in the game so far! Nice find!
It's from this commit (but I only added that to the script branch). I thought that it would be useful to know all of the available color codes, so I simply tried them all and made up names for the missing ones... I did not know at that point that they were the colors of a "standard" 4-bit palette.David wrote:The current version does not have all those names.Falcury wrote:so I guess these names in types.h are not really correct:
Where does "color_3_turquoise" come from, for example?
Code: Select all
#ifdef _WIN32
#include <winsock2.h>
#include <Ws2tcpip.h>
#else
#include <sys/socket.h>
#include <arpa/inet.h>
#endif
Code: Select all
/*** Make non-blocking. ***/
#ifdef _WIN32
u_long iMode=1;
ioctlsocket(iSSocket,FIONBIO,&iMode);
#else
//...
#endif
Code: Select all
target_link_libraries(prince mingw32 SDL2main SDL2 SDL2.dll SDL2_image SDL2_mixer ws2_32)
target_link_libraries(pserver mingw32 SDL2main SDL2 SDL2.dll SDL2_image SDL2_mixer ws2_32)
I personally do like David's style, but as you say it can be very personal. And there are probably many separate elements to it. If you want to discuss the specific points, it will be a bit easier for me to form an opinion then.Norbert wrote:This is not a problem per se/an sich, but, in my opinion, generally speaking, the layout, comments and formatting of the SDLPoP code is not very pretty. I would like to make all the code more readable. David will know what I mean by this. I've done it with (parts of) CusPop in the past, and I started doing it with his code that exports SNES resources. This would be a lot of work. More importantly, it would change the coding style, and coding styles can be very personal. I could also make mistakes and introduce errors, I've made them in the past - not many, but still. And I'd have to do this with a more recent version of SDLPoP that includes changes that were made since version 1.16. Also, it would essentially mean that other people could not touch the code while I'm changing it, unless they are willing to later merge it by hand. Just some thoughts. Let me know what you think, David, Falcury, others.
Yeah. How about this: pick one SDLPoP function for me and I'll show you how I would format it. Maybe pick a fairly long function with a lot of different things in it, like variables/assignments/switches/ifs/fors/comments, etc.Falcury wrote:And there are probably many separate elements to it. If you want to discuss the specific points, it will be a bit easier for me to form an opinion then.
Like I said, I'm unfamiliar with network programming... as long as it works on Windows as well as everything else I'm happy!Norbert wrote:I think it's better to stick with more portable code and to avoid using Winsock; there's no need for it.
Not to be too defensive, but I think this requires a bit of a rebuttal! Especially as I too try to work in David's style.I think both poirot and David are exceptionally smart people, but both produce code that's unnecessarily unreadable. Not because the code is difficult, but because they barely seem to put any effort into making it neat. (As in clean, tidy.)
On the other hand: the style is dense, which may actually be an advantage at times, if only because more code fits on the screen.It's all just one stream of messy code.
I am not bothered by this.the most basic structure, like where functions start and end, is absent
In general I think the conventions David uses are good? In what context do you think there should me more newlines/spaces/brackets?Newlines are used very scarcely. The same goes for spaces and brackets.
I have used CamelCase in the past, now I use lower_case - I found that it really doesn't matter very much. It's just a convention. Muscle memory adapts quickly enough.Everything is lower case
In my opinion this is actually a significant advantage. Only useful (identifying) information in variable names means a higher signal-to-noise ratio. It's easy enough to remember what type a variable is.variables aren't identifiable by types
What do you have in mind that is too shorthand?everything is shorthand
OK, I hope I wasn't overzealous. I do appreciate your own neat style of course, it certainly has a systematic elegance to it.Norbert wrote:I don't feel like doing a back and forth about this, sorry.
Just keep the code as is. I don't mind.
This reminds me of something I saw in some cartoon: They took something apart and put it together again, but some parts were left out.Falcury wrote:For some reason, the dll size is smaller compared to official release from on libsdl.org (746 KiB vs 1023 KiB).