Planning for Release

Mar 14, 2015, 10:08 pm
#51
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 842
capristo wrote
Back on the topic of releases. There was some discussion on Github here

https://github.com/Attnam/ivan/pull/21

Seems like the concensus is that Attnam/master is the working space, NOT the "stable" version. Stable versions will instead be released as tags.

I can fork Attnam/master into capristo/master and then make my own changes. After I have tested my changes, I submit a pull request to Attnam/master which is merged in so that everybody else can test.

If I have a larger feature that will take a long time to complete, I can branch my own fork into capristo/FireSystem. Then when I am comfortable with this feature being complete, I should first merge into capristo/master, and then submit a pull request as usual to Attnam/master.

Then to release specific versions, we should use git tagging because that is basically what it was built for and what Github supports out of the box. For example, after my capristo/FireSystem branch has been merged in, we tag this as version 0.51. All commits up to this point are now released as version 0.51 and can be downloaded as a zip. Then if we fix a few bugs related to the fire system, we can release this as 0.51.1. The next batch of bugs is tagged 0.51.2 and so on. Then when we add the next big feature, call it 0.52.

We should stick to semantic versioning as much as possible:

0.51.2
0 - major release
51 - minor release, increment when adding new features
2 - patch, increment when releasing bug fixes which don't add new functionality

That was designed for APIs. I am ok with using a letter to denote the patch instead, e g. 0.51a, 0.51b

Ok so from this it seems I need to make a fork of master, and then make a feature branch (firesubsystem) from the fork. Got it

Edit: So I did this and consolidated the other branches that were swimming alongside my fork. It seems to me that small, self-contained changes should indeed be merged early and often, whereas a larger subsystem should be worked on and tested to some degree before merging into master.

The question is, if I want some testing done, should I release on my own fork?
Mar 15, 2015, 11:46 am
#52
Joined: Feb 20, 2012
Posts: 232
Warheck wrote
The question is, if I want some testing done, should I release on my own fork?

You should probably merge the branch into the main repo and then do a testing release there, so they aren't scattered around different repos.

Or you could just post some binaries here to keep it clean.
Apr 10, 2015, 10:42 pm
#53
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 842
Ok after some long hard labour there is another release: IVAN 0.50.2

Will post changes soon.
Jun 12, 2015, 5:40 pm
#54
Joined: Jun 11, 2015
Location: Paris, France
Posts: 6
Hi,

I've made a preliminary port of Ivan with SDL2 ( https://github.com/murlock/ivan )

If you are interested to integrate it, I'll finish support as few tasks remains (partial keyboard support, cleanup code (removing djgpp ?), and autoconf integration)

Murlock, an old player of Ivan 15 years ago
Jun 12, 2015, 9:30 pm
#55
Joined: Dec 4, 2007
Occupation: Scribe of Hamr
Location: A candlelit, soundproofed room, covered in blessed runes
Interests: Chronicling His work
Posts: 1,050
Wow, 15 years? Damn, I'm pretty sure that means you've been around longer than anyone currently on the forums. We're glad to have you.
Jun 13, 2015, 1:44 am
#56
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 842
murlock wrote
Hi,

I've made a preliminary port of Ivan with SDL2 ( https://github.com/murlock/ivan )

If you are interested to integrate it, I'll finish support as few tasks remains (partial keyboard support, cleanup code (removing djgpp ?), and autoconf integration)

Murlock, an old player of Ivan 15 years ago

Yes we are interested to integrate this Thanks so much for taking the time to do this Murlock, this is probably one of the most important things to be done in the project.
Jun 13, 2015, 11:53 am
#57
capristo's avatar
The Imperialist


Joined: Dec 2, 2007
Location: New Attnam
Interests: bananas
Posts: 1,906
Awesome, murlock! Thanks so much for contributing. Just submit a pull request when everything's ready
Jun 17, 2015, 3:32 pm
#58
Joined: Jun 11, 2015
Location: Paris, France
Posts: 6
Hi guys,

I've just made a pull request ( https://github.com/Attnam/ivan/pull/36 ) to master branch.
As mentioned, I didn't check if it is ok on BIG_ENDIAN. I'll try to do it as soon as I've more free time.

Enjoy

PS: I'm maybe an old Ivan's player but, unlike wine that gets better with age, I'm still playing like a newbie
Jun 18, 2015, 11:46 am
#59
Joined: Jun 23, 2014
Occupation: computer science student
Location: Helsinki, Finland
Interests: Programming languages, language design, compilers, music production
Posts: 25
Inspired by murlock's SDL2 patch, a thought crossed my mind — Should we perhaps convert the project to C++11 as well?

I mean, IVAN currently uses C++98, which is already 17 years old. I think C++11 would be a great step forward.

Some of the C++11 features I'd love to have in the IVAN source code include smart pointers, override (and final), delegating constructors, range-based for, constexpr, auto, = delete, = default; maybe also: new algorithms in <algorithm>, decltype, lambdas, enum class, static_assert; to name a few.

This is of course a lot of work. I think it could be manageable in chunks, one feature at a time. And not necessarily all of the above. I'd be happy to do this. If anyone wants to help, that'd be awesome.

What do you think?
Jun 21, 2015, 5:56 am
#60
Joined: Dec 4, 2007
Posts: 178
I just had a thought. You could totally include Bleeding as a feature of damage. All you would really need to do would retool critical hits to inflict a different form of poisoning; and name it bleeding. Makes sense, sort of; but it'd have to affect slashing/stabbing/lacerating weapons... Though, crushing weapons could be a thing; if we had a method of inflicting limb damage to make them black ('useless due to being broken, causing a person to limp or be unable to use their limb'.

Though, all of that stuff would be... Well, kind of un-needed.
Jun 22, 2015, 5:28 am
#61
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 842
After some fooling around in git, there is a new windows release here:

IVAN 0.50.3

It ships with the 32-bit version of SDL2.dll

Thanks to Murlock and Zenith for the patch to SDL 2.0, it is a huge milestone.
Jun 22, 2015, 6:25 am
#62
Joined: Jun 11, 2015
Location: Paris, France
Posts: 6
Happy to know that Windows version works, and thanks for Zenith for help

I've small patches for
- on unix, allow to launch ivan without install it
- update error message with link of forum

I want also to clean up some weird test in code (missing brackets) that make code difficult to read (as mix of indentation with space or tabs) and remove DJGPP stuff.

For C++ 11, I'm agree that code need a revamp to clarify it but I'm not an C++ expert, still, I can help
Jun 22, 2015, 2:52 pm
#63
Joined: Jun 23, 2014
Occupation: computer science student
Location: Helsinki, Finland
Interests: Programming languages, language design, compilers, music production
Posts: 25
No problem, glad to help!

Regarding the mixture of spaces and tabs in the code, and some slight variations on coding styles, etc.:

I think that, especially now that multiple people have started contributing to the project, we should establish a set of explicit rules, some kind of "IVAN coding standard / style guide", to help keep the codebase consistent and clean, as it was at the time of the original v0.50 release.


Regarding DJGPP, I agree that it clutters the graphics code a bit, but just last year I ran IVAN on my ancient computer with DOS (just for fun) and it actually worked. So I think it's a nice feature to have, and it would be a shame to just throw it away, even though nobody uses DOS on a daily basis. (Also it adds geek value.)
Jun 23, 2015, 12:11 am
#64
Joined: Dec 3, 2007
Occupation: Chaos Weaver
Location: Standing between all life and death.
Posts: 2,711
Haha, geek value XD

Right, I officially nominate zenith for MVP 2015.
Jun 23, 2015, 6:38 am
#65
Joined: Jun 11, 2015
Location: Paris, France
Posts: 6
Supporting DJGPP and C++11 at same time seems very difficult
Jun 23, 2015, 8:21 am
#66
Joined: Jun 23, 2014
Occupation: computer science student
Location: Helsinki, Finland
Interests: Programming languages, language design, compilers, music production
Posts: 25
chaostrom, hah!

murlock wrote
Supporting DJGPP and C++11 at same time seems very difficult

Excellent point. If we're going to integrate C++11 then I think DJGPP is of less priority and should be dropped.
Jun 23, 2015, 10:28 am
#67
capristo's avatar
The Imperialist


Joined: Dec 2, 2007
Location: New Attnam
Interests: bananas
Posts: 1,906
Awesome, thank you everyone for the contributions in the SDL 2 update.

My vote would be to go ahead with C++11 and drop DJGPP. It's a shame but as someone who writes PHP all day and sees the huge benefits of newer PHP versions, I can appreciate the need to update the code.
Jun 25, 2015, 7:14 am
#68
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 842
Cap can you try the version in the attachement to this post? It's compiled with SDL 2.0.4. I fear it might have the same problem with the (g)o button as before. All the same, see if it works better.
Jun 26, 2015, 6:45 am
#69
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 842
Sorry for the double post.
zenith wrote
Regarding the mixture of spaces and tabs in the code, and some slight variations on coding styles, etc.:

I think that, especially now that multiple people have started contributing to the project, we should establish a set of explicit rules, some kind of "IVAN coding standard / style guide", to help keep the codebase consistent and clean, as it was at the time of the original v0.50 release.


Regarding DJGPP, I agree that it clutters the graphics code a bit, but just last year I ran IVAN on my ancient computer with DOS (just for fun) and it actually worked. So I think it's a nice feature to have, and it would be a shame to just throw it away, even though nobody uses DOS on a daily basis. (Also it adds geek value.)

I think it is a good idea to move on C++11, and I will support it. As to coding style, for starters is it ok if we stick to "BSD style", with two-space indentation?
Jun 27, 2015, 4:54 pm
#70
Joined: Jun 23, 2014
Occupation: computer science student
Location: Helsinki, Finland
Interests: Programming languages, language design, compilers, music production
Posts: 25
Warheck wrote
[…] is it ok if we stick to "BSD style", with two-space indentation?

Yes, those, no tabs, and any other consistencies we can find in the original source code, off the top of my head:
* no braces for 'if's, 'while's, etc. if they contain only one statement
* no space between 'if', 'while', etc., and the following '('
* 'lowercasewithoutunderscores' for type names, 'PascalCase' for variable names
* no space between type name and '*' / '&' in variable declarations
* comments start with a capital letter

There are also some inconsistencies that we should probably fix. For example sometimes '&' and '|' have no space around them but there's also lots of code with spaces around them. I think they're more readable with spaces.

Maximum line width? There are some ridiculously long lines that don't really contribute to readability. Would something like 90 or 100 be good? With 90 I can fit two pages of code side by side in my editor which is really handy.
Jun 27, 2015, 6:27 pm
#71
capristo's avatar
The Imperialist


Joined: Dec 2, 2007
Location: New Attnam
Interests: bananas
Posts: 1,906
Are there any C++ coding standards already out there?

PHP has PSRs: www.php-fig.org/psr/psr-1/
Jun 28, 2015, 6:57 pm
#72
Joined: Jun 23, 2014
Occupation: computer science student
Location: Helsinki, Finland
Interests: Programming languages, language design, compilers, music production
Posts: 25
capristo wrote
Are there any C++ coding standards already out there?

Yup, it's just a matter of finding one that doesn't conflict with IVAN's existing style too much.

Some that I've enjoyed reading are the JSF Air Vehicle (really extensive), LLVM (compiler) and Juce (audio engine) coding standards, and the EECS 381 course material, to name a few.

While these are really good for general (C++) programming style and best practices, they might clash with IVAN's existing style in some areas. To cover that we could make a minimal list of things that are "unique" to IVAN, and for all other more general stuff refer to some external coding standard.
Jun 29, 2015, 8:46 am
#73
Joined: Feb 20, 2012
Posts: 232
In the spirit of keeping to the original style, I propose we forego comments and documentation entirely, then vanish without a trace when the project is halfway completed (in this case 0.75).
Jun 30, 2015, 1:37 am
#74
Joined: Dec 3, 2007
Occupation: Chaos Weaver
Location: Standing between all life and death.
Posts: 2,711
lmao Pent
Mar 27, 2016, 5:57 am
#75
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 842
capristo wrote
Can we get a new Windows release?

And so here it is, a windows binary for IVAN 0.50.5.
Jump to