Planning for Release

Mar 14, 2015, 10:08 pm

#51

archangel

Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 1,216

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?

Edited 2 times

Batman? wrote

its been so long since i had gotten that far i didnt think it through. arrrr!!!!!!

Mar 15, 2015, 11:46 am

#52

wolf

Joined: Feb 20, 2012
Posts: 231

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

archangel

Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 1,216

Ok after some long hard labour there is another release: IVAN 0.50.2

Will post changes soon.

Batman? wrote

its been so long since i had gotten that far i didnt think it through. arrrr!!!!!!

Jun 12, 2015, 5:40 pm

#54

hedgehog

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

He Who Scars

Joined: Dec 4, 2007
Occupation: Perfect Soldier
Location: Astragius Galaxy
Interests: Fiana, Peace, Melons
Posts: 1,057

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.

Proudly bringing disaster and mental scarring to Attnam since '05!

"You have a rather pleasant chat about finite superarmpits with Sanae the shrine maiden."

You hear distant shuffling.

The Enner Beast tells you to COOL IT!!

Jun 13, 2015, 1:44 am

#56

archangel

Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 1,216

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.

Edited 1 time

Batman? wrote

its been so long since i had gotten that far i didnt think it through. arrrr!!!!!!

Jun 13, 2015, 11:53 am

#57

The Imperialist

Joined: Dec 2, 2007
Location: New Attnam
Interests: bananas
Posts: 2,309

Awesome, murlock! Thanks so much for contributing. Just submit a pull request when everything's ready

Jun 17, 2015, 3:32 pm

#58

hedgehog

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

zombie

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?

Edited 1 time

Jun 21, 2015, 5:56 am

#60

blink dog

Joined: Dec 4, 2007
Posts: 184

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

archangel

Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 1,216

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.

Edited 1 time

Batman? wrote

its been so long since i had gotten that far i didnt think it through. arrrr!!!!!!

Jun 22, 2015, 6:25 am

#62

hedgehog

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

zombie

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

Mage Prophet

Joined: Dec 3, 2007
Occupation: Chaos Weaver
Location: Standing between all life and death
Posts: 2,898

Haha, geek value XD

Right, I officially nominate zenith for MVP 2015.

Uchuudonge wrote

creating stable chaos
making patterns where there should be none
sewing order into the chaos
you spit in the face of random numbers, of chaos

Jun 23, 2015, 6:38 am

#65

hedgehog

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

zombie

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

The Imperialist

Joined: Dec 2, 2007
Location: New Attnam
Interests: bananas
Posts: 2,309

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

archangel

Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 1,216

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.

Batman? wrote

its been so long since i had gotten that far i didnt think it through. arrrr!!!!!!

Attached files
IvanWin05031.zip (2.01 MB)

Jun 26, 2015, 6:45 am

#69

archangel

Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 1,216

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?

Batman? wrote

its been so long since i had gotten that far i didnt think it through. arrrr!!!!!!

Jun 27, 2015, 4:54 pm

#70

zombie

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

The Imperialist

Joined: Dec 2, 2007
Location: New Attnam
Interests: bananas
Posts: 2,309

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

zombie

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

wolf

Joined: Feb 20, 2012
Posts: 231

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

Mage Prophet

Joined: Dec 3, 2007
Occupation: Chaos Weaver
Location: Standing between all life and death
Posts: 2,898

lmao Pent

Uchuudonge wrote

creating stable chaos
making patterns where there should be none
sewing order into the chaos
you spit in the face of random numbers, of chaos

Mar 27, 2016, 5:57 am

#75

archangel

Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 1,216

capristo wrote

Can we get a new Windows release?

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

Batman? wrote

its been so long since i had gotten that far i didnt think it through. arrrr!!!!!!