Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bramcor

Pages: 1 [2] 3 4
16
Programming / Re: Ocean colouring - Version 2
« on: December 23, 2010, 03:15:01 pm »
Marabus: I see the day/night gradient is broken in some special cases, but it is only slightly worse than before ;)

Happy news is I went from ~40fps to ~60fps in geoscape view.

17
Suggestions / Re: MUST HAVE list by a die-hard fan
« on: December 12, 2010, 07:13:05 pm »
Daiky:

I am just wondering here - it probably has little to no effect on practical results and I have no clue how to make it happen, but:

Would using normal distribution on two axis not "look like" a diamond shaped probability distribution with a corner in each direction on both axis if you imagine seeing it from the solider's point of view?

I just thought to myself that a circular probability distribution seem more "correct" but my gut response is that the practical difference in results is too limited to warrant the difficulty of making it any different.

What are your thoughts?

18
Troubleshooting / Re: Trouble saving in Win7?
« on: December 09, 2010, 10:02:37 am »
That's easy - save games are not implemented yet, just like lots and lots of other features.

Have a look at the roadmap on the about page: https://openxcom.ninex.info/index.php/about/

OpenXcom is currently at v0.1

19
Programming / Re: Battlescape development
« on: December 03, 2010, 02:25:35 pm »
I have a backlog of battlescape bugs that I just haven't gotten around to posting yet .. been a bit busy lately, you see ;)

I have also observed the rendering problem for corners where wooden fences meet! Which make me think that it is likely to be the same for all other tiles that meet in a corner in the same manner (walls in houses, hedges and whatnot)

20
Suggestions / Re: externalization of small bitmaps that are now hardcoded
« on: November 18, 2010, 01:48:59 pm »
Hardcoded "graphics" probably don't fall under copyright rules if they are generated algorithmically. The output of such an algorithm can probably be distributed safely, or the functionality of the algorithm could be replicated by various means.

However, if I understand correctly, copyright does extend to all content of an artifact (a game in this case), whatever form it might have. So even if the 3x3 px squares are hardcoded into an executable file bit by bit its form does not differ much from the representation it would have in a PCK or SPK file. Thus it is likely that it is covered by the same copyright terms as the rest of the game content.

I am quite sure we are free to replicate (not copy from the source) such trivial graphics as a 3x3 px blob on our own if it does not breach a trademark (fx. this might be the case with the graphic update for The Two Sides due to the very specific replication of UFO:EU's characteristic character and vehicle design) or a patent (which would be next to impossible to achieve for the graphics themselves as patents are usually connected to processes of creating artifacts in non-trivial manners).

In terms of copyright it all comes down to whether you are "licensed" to distribute a work (or parts of it) created by another person/entity than yourself.

I am no expert in the field though ;)

21
Suggestions / Re: externalization of small bitmaps that are now hardcoded
« on: November 18, 2010, 03:47:22 am »
If that was done, would you not have do distribute the copyrighted graphics with the c++ code to make things work? Distributing copyrighted work without consent is usually a bad idea :P

Another option might be to create placeholder graphic files for each that the player could swap out with his own stuff. I guess OpenXcom would have to scan the placeholders for bit-changes from the original placeholders at each launch or something to know which to include instead of the originals extracted from the DATA folder...

Just a thought ;)

22
Open Feedback / Re: OpenXCom and hqx scaler
« on: November 09, 2010, 10:30:10 pm »
I would love a more efficient scaler, but like michal I prefer the pixelated look personally.

"Oil painting" is a polite description - in my experience the effect as downright creepy. Maybe not such a bad thing for a game about aliens and UFOs ;)

23
Programming / Re: Battlescape development
« on: October 29, 2010, 01:35:52 am »
Great job with the patch Daiky! It is great to have a use for that Skyranger ;)

From what I can tell, your terrain detection is spot on. I tried out farm, forest, jungle, desert, mountains and polar. All of them corresponded to the correct globe surfaces.

Only thing that caught my eye was a few warnings during compilation. I pasted them here: https://pastebin.com/rNjy5jbK

24
Suggestions / Re: Rearming Skyrangers after returning from missions
« on: October 19, 2010, 10:56:17 pm »
Yeah, I also though of adding something such as "soldier equipment maintenance" or "unloading loot" to the list of states a recently landed craft could go through. This would definitely make them more descriptive, but along the way I thought to myself that adding yet another state would make the whole thing too complex for a change that would fit with the purpose of OpenXcom.

And I guess that is the answer I was looking for in the first place - adding the number of states that would describe the degree of detail I am interested in should not happen in this incarnation of OpenXcom. It will have to wait for some distant future version or a mod of some sort :)

25
Programming / Re: Battlescape development
« on: October 18, 2010, 08:16:04 pm »
Battlescape works flawlessly on Ubuntu x64!

Only problem was patching, which caused some hunk fails with vcproj file. Compiled with a few warnings in Tile and XcomRuleset, but they seemed to have no effect on running the game.

Chek out the fails and warnings at https://pastebin.com/iqPGcDKc

Screen edge scrolling is a bit choppy and difficult to control but I am sure that is a WIP ;)

26
Open Feedback / Re: Congratulations for 0.1 release
« on: October 18, 2010, 12:56:09 pm »
I would like to congratulate SupSuper too! Time to break open that bottle of champagne and host a release party ;)

The time, energy and dedication you put into this project motivate me to give back what I can to the project, so it gets one step closer to being all that it can be.

I am also very impressed with the contributions made by the rest of you guys who follow the project closely and hang out on IRC.

Keep up the good spirits and lets crank it up to 11!

27
Offtopic / What scale do you play OpenXcom at?
« on: October 17, 2010, 05:12:31 pm »
I was wondering what scale you guys play OpenXcom at and why?

I like to go for 3x or 4x depending on resolution of the screen I use. In part to make buttons large enough to tell apart and hit them with the cursor, but also because I like the pixelated aesthetics as I remember them from playing UFO:EU on my old 15" monitor :)

So do you guys take it as closely as possible to fullscreen extravaganza or do you enjoy keeping it tight at 320x200 px?

28
Suggestions / Rearming Skyrangers after returning from missions
« on: October 17, 2010, 03:09:07 pm »
Although https://www.ufopaedia.org/index.php?title=Skyranger makes it clear that Skyrangers (well - unarmed crafts in general I guess) have a rearming step after returning from a mission in the original game, it might make better sense to split up the rearming procedure https://www.ufopaedia.org/index.php?title=Rearming into rearming and readyness check procedures.

This would mean that crafts with no weapon mounts or no weapons mounted would just go through the readyness check after refuelling/repairing before being ready for action again.

From how I interpret the description on https://ufopaedia.org an additional hour of maintenance is currently imposed on the craft through the rearmament step in addition to the time requirements of the "hidden" readyness check.

Changing this would be a clear deviation from the original implementation, but I would argue that it still fits in with the goal of creating a remake to the degree that it makes sense. Is this a fringe case where the logic of UFO:EU is wrong, or should it remain the same as in the original? What do you guys think?

29
When placing base facilities larger than 1x1 squares (which is basically just the hangar as-is), the facility outline indication under the cursor disappears when the cursor hovers above the bottom row and the rightmost column. When clicking LMB to place the facility the error dialog that appears is related to non-connectedness with other facilities rather than its "out of base bounds" placement.

Making special cases for outline placement in relation to cursor position when over bottom row and rightmost column could solve the problem. By default the cursor is in the top-left square of the facility placement outline. When the cursor hovers over the bottom row it could be in the bottom-left square. When the cursor hovers over the rightmost column it could be in the top-right square. And when the cursor hovers over the bottom row *and* the rightmost column (the bottom-right square of the base grid) it could be in the bottom-right square.

Such a change would also be useful if anybody decided to implement strange and wonderful new facility types larger than 1x1 square sometime in the future!

From talking to SupSuper I realize that he actually implemented facility placement to original spec - I forgot to have a look at UFO:EU before I reported it as a bug. It seems the original implementation continues to baffle with its bad usability.

30
Suggestions / Re: Make OpenXcom easier to use than original UFO!
« on: September 04, 2010, 03:03:57 pm »
... what if some of your users are colourblind?

Dammit - I wish I had thought of that :)

However it is a very difficult problem to embrace, as it would most optimally happen as early as concept development, when different color scales are picked out for the tone of a game. During development or even now, as the game is being remade, it is excessively difficult to implement changes to the graphics that are functional (aka usability-focused & colorblind-friendly) as well as pretty (aka following the vision/tone of the graphic design).

From a holistic point of view there seem to be few "good" solutions to such problems.

Pages: 1 [2] 3 4