by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 26 09:34
    mogemimi closed #41
  • Feb 25 02:05
    mogemimi reopened #41
  • Feb 25 02:05
    mogemimi closed #43
  • Feb 25 02:05
    mogemimi closed #41
  • Feb 24 17:49
    mogemimi opened #43
  • Feb 15 11:44
    mogemimi closed #42
  • Feb 15 09:54
    mogemimi synchronize #42
  • Feb 15 09:25
    mogemimi synchronize #42
  • Feb 15 07:58
    mogemimi synchronize #42
  • Feb 15 06:12
    mogemimi opened #42
  • Feb 15 05:36
    mogemimi edited #41
  • Feb 15 05:34
    mogemimi labeled #41
  • Feb 12 05:08
    Bakedanuki opened #41
  • Dec 10 2019 02:43
    mogemimi closed #39
  • Dec 10 2019 00:42
    mogemimi closed #40
  • Dec 10 2019 00:39
    Bakedanuki reopened #39
  • Dec 10 2019 00:39
    Bakedanuki closed #39
  • Dec 09 2019 21:28
    mogemimi opened #40
  • Dec 09 2019 21:14
    mogemimi edited #39
  • Dec 09 2019 21:08
    mogemimi labeled #39
barsoosayque
@barsoosayque

Aw, and I just build all experimental stuff right into the core library. Gotta fix that.

Ok, it seems that separate builds are not provided, since I am getting alot of undefined reference to the core library.

mogemimi
@mogemimi

why these files still 'marked' as experimetal ?

There are some reasons for this, such as the following:

  • These features are literally "experimental", not stable.
  • To keep core simple and lightweight as possible, it doesn't depend on any specific game genre.
  • However it is too hard to develop a game using core library only, so pomdog provides any genre-dependent features (like 2D particle system, 3D deferred renderer or 2D platformer physics etc.) as experimental instead.
  • To provide a minimal engine for customization, the core library must be able to build without experimental library.

I guess "Extensions" or "Modules" would be more appropriate than Experimental.

I'm thinking about opening an issue about it, ...

This sounds like a good proposal! I'll open a new issue about it. :+1:

barsoosayque
@barsoosayque

I don't really know if I should open issues regarding engine-related questions, well, guess it's better to just chat about it. I've never seen __declspec directive before, so I was curious about it. I am personally not a fan of macros, however sometimes it seems that macros is the only way to optimize something or make it pretty.

As far as I can tell, __declspec directive is MSVC-specific, and with dllexport it tells the compiler to export symbols into the shared library. In Unix I don't really ever build a shared library, but it seems that there are no mandatory macros to do that. However, in GCC there is __attribute__ (( visibility .. )) macro that seems to boost performance.

After a while of googling around, I realize that there are ways to make the export macro simpler.

  1. First one is GENERATE_EXPORT_HEADER function for the CMake. Basically, it is Export.hpp file, but generated by CMake.

  2. Second option is to utilize CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS CMake property. That is pretty neat, although static data still should be decorated with export macro. From CMake help:

    For global data symbols, __declspec(dllimport) must still be used when compiling against the code in the .dll

    But I don't know if there are static variables or something in pomdog.

I'm just thinking that without the export macros code will be cleaner and more readable. Probably, these are just personal preferences !

barsoosayque
@barsoosayque
Ah, I'm trying to make text rendering work in a slight panic. Very confused about the camera part. I do 2D game, so I don't really need a z-position, but rather I may need zooming. However there is z-position from Transform component, and zoom from Camera component. And there's more. When I create default camera with entity manager, and then default text renderable, nothing renders in the game window (By tweaking the camera later, I did saw the text). What I am supposed to do to use entity manager inside of 2D game ? 😵
More specifically, how should I configure the camera to achieve pixel-perfect rendering ?
mogemimi
@mogemimi

I am not a fan of preprocessor macros either, and I'd like to remove as many unnecessary things as possible. :smile_cat:

In Unix I don't really ever build a shared library, but it seems that there are no mandatory macros to do that. However, in GCC there is attribute (( visibility .. )) macro that seems to boost performance.

You are right. For your information, pomdog uses -fvisibility=hidden option with __attribute__((visibility)) in Apple Clang (Xcode).

After a while of googling around, I realize that there are ways to make the export macro simpler. ...

I will try it later. :+1:

Also I have not done shared library supporting on CMake yet, so I just opened issue mogemimi/pomdog#20 .

mogemimi
@mogemimi
@barsoosayque I will make sure it works for pixel-perfect rendering :running:
barsoosayque
@barsoosayque
Aww, I decided to skip the LD42, because it would not be fun to work in such a rush and confusion. I came up with a better plan: reading pomdog until winter, and writing documentation alongside with my study !
barsoosayque
@barsoosayque

Code style question (or rather code etiquette): class getters/setters is here because of the more sustainable API, or is this, like, some code conventions ? At first I thought that getters/setters would put weight in the build, but then I got these numbers for the core pomdog and a simple game:

     |  debug  | release |
-----+---------+---------|
 exe |  12 mb  | 0.70 mb |
-----+---------+---------|
 lib |  29 mb  | 2.78 mb |

Which is sweet.

colajam93
@colajam93

Hi.
I tried to build pomdog on Linux with GCC 8.2.0, but I got the following error:

pomdog/src/Content/Utility/MSWaveAudioLoader.cpp:399:19: error: declaration of ‘Pomdog::Detail::{anonymous}::PcmWaveFormat Pomdog::Detail::{anonymous}::WaveFormat::PcmWaveFormat’ [-fpermissive]
     PcmWaveFormat PcmWaveFormat;
                   ^~~~~~~~~~~~~
pomdog/src/Content/Utility/MSWaveAudioLoader.cpp:389:8: error: changes meaning of ‘PcmWaveFormat’ from ‘struct Pomdog::Detail::{anonymous}::PcmWaveFormat’ [-fpermissive]
 struct PcmWaveFormat {
        ^~~~~~~~~~~~~

It seems the GCC treats as error that declaring a variable which name is same as the type name, but with the Clang this is no problem.
There some APIs contains such code so renaming it may cause compatibility issues.
I have no idea to fix this...
Are there any plan to support GCC?
Thanks.

barsoosayque
@barsoosayque

@colajam93 I tried to build with gcc once too (but by accident), got redefinition errors. It was fixed in mogemimi/pomdog@86db5de however. And if I recall correctly, @mogemimi said that GCC is in plans. Well, I actually found the message:

... but I have a plan to support GCC and libstdc++ in CI

colajam93
@colajam93
@barsoosayque Thank you for replying! That sounds great. I'm using Arch Linux for my personal machine. In Arch, default compiler is GCC and Clang + libc++ is not supported officially...
mogemimi
@mogemimi
Sorry for the late reply. I was off work this weekend.

Aww, I decided to skip the LD42, ...

@barsoosayque oh I got it. Pomdog is still in chaos, so I hope to make it stable by Ludum Dare 43 (Dec 2018) at the latest. If you want something (such as docs, cmake, pixel-perfect rendering or gamepad support etc.) as a higher priority for gamedev, please post in Gitter or directly raise an issue in GitHub, I'll try to fix/add them as soon as possible.

barsoosayque
@barsoosayque

Well, the only thing that stopped me was camera. I couldn't figure it out back then. I think, it would be just perfect, if orthographic camera by default will be pixel-perfect, and then I can zoom it, use translation with it, etc. Just a thought, it might be pixel perfect, but for me TTF-fonts were blurry and somehow disposed in a wrong place.

Also, regarding docs, I'm now wrapping my head around pomdog code in my spare time, and trying to leave notes (currently, only two classes in core/Application). Hoping to write something really helpful and make a PR.

mogemimi
@mogemimi

Code style question (or rather code etiquette): class getters/setters is here ...

The code size is reduced because the optimization works in release mode with the compiler options -Os, -Oz or -O3 (e.g. inline expansion, link-time optimization etc.)

Pomdog doesn't have an explicit coding standard yet, but it is customary to declare as follows like Golang and C#.

class Actor final {
    std::string name;
    bool blurEnabled;

public:
    std::string GetName() const { return name; }

    // To avoid variable shadowing, we conventionally add `In` suffix to parameter name.
    void SetName(const std::string& nameIn) { name = nameIn; }

    // If you avoid unnecessary copying for performance, you can add move-semantics in setter.
    // Also please add `const`, `override` and `noexcpet` keywords whenever possible.
    void SetName(std::string&& nameIn) noexcept { name = std::move(nameIn); }

    // The prefix of boolean getters are `Is` or `Has` according to circumstances.
    bool IsBlurEnabled() const { return blurEnabled; }
    void SetBlurEnabled(bool enabled) { blurEnabled = enabled; }
};

Comparison from C++ standard is the following:

// C++ standard style
const T* data() const;
bool empty() const;
bool has_value() const;

// Pomdog
const T* GetData() const;
bool IsEmpty() const;
bool HasValue() const;

In addition, "Excessive" getter/setter functions are not my favourite. For example, when defining a 2D vector class, I guess they such as the following should be avoided as much as possible.

class Vec2 final {
    float x_, y_;
public:
    float getX() const noexcept { return x_; }
    float getY() const noexcept { return y_; }
    void setX(float x) noexcept { x_ = x; }
    void setY(float y) noexcept { y_ = y; }
    float length() const { return std::sqrt(x * x + y * y); }
};

In this case the following style is more preferable for me:

struct Vec2 final {
    float x, y;
    float length() const { return std::sqrt(x * x + y * y); }
};

However, there (maybe) is not much difference in code size between both cases if it is optimized.

mogemimi
@mogemimi

Hello @colajam93 thank you for the feedback!

To fix -fpermissive warning on GCC, we can use same name with an explicit namespace.

Pomdog::Detail::PcmWaveFormat PcmWaveFormat;

I'll fix the GCC warning, and also try create Arch Linux + GCC container for this to run tests on CI.

mogemimi
@mogemimi
I've just fixed the gcc compilation error in mogemimi/pomdog#21
mogemimi
@mogemimi

@barsoosayque Aww, I'm sorry I missed your message.

it would be just perfect, if orthographic camera by default will be pixel-perfect ...

Hmm I see. I'll try it and fix TTF rendering this weekend.

Also, regarding docs, I'm now wrapping my head around pomdog code in my spare time

Wow, that looks great! I'm looking forward to your pull request. :smiley_cat::thumbsup:

barsoosayque
@barsoosayque

Ah, I described another class (it is GameWindow), and noticed one neat feature (among other benefits from the documentation): doxygen can generate special page with TODOs. Because for some platform-specific class methods, some of them are not implemented yet. And doxygen can track them all.

And now I'm trying to understand Timer class, but it'll be easier for me to ask. What is the purpose of the Timer ? I thought that it's to invoke callback after the time is over, but guess it's not. Is it some kind of low-level core mechanism ?

mogemimi
@mogemimi

@barsoosayque The TODO-list page is very useful. I'd like to get the tasks done gradually.

I thought that it's to invoke callback after the time is over

You are right. Timer literally represents a timer (or stopwatch) which counts upwards from zero. When you set the time interval through Timer::SetInterval(), the callback will be called from Timer::Elapsed() when timer is expired.

... but guess it's not. Is it some kind of low-level core mechanism ?

No, it doesn't have any special mechanism. Instead of Timer, GameClock have a platform-independent layer which provided as TimeSource, and each GameHost classes call the clock's Tick() function every frame, such as the following:

barsoosayque
@barsoosayque
Yes, I somehow overlooked the Signal-member of the Timer.. I'm used to std::function as definition of callback in cpp, so I understand why it happened to me. 😖
mogemimi
@mogemimi
oh, no problem. I'm glad to help :relaxed:
barsoosayque
@barsoosayque
@mogemimi, what do you think of moving all deleted constructors and methods to private ? In my doxygen configuration right now only public members are generated, but also all the deleted stuff is presented here. This is not very convenient since neither I can actually use those methods nor I need to document them. And as for public API, it doesn't make any difference here. I guess..
mogemimi
@mogemimi

@barsoosayque According to StackOverflow, it seems to be different only the diagnostics.
Also, Scott Meyers says "By convention, deleted functions are declared public, not private. ..." (Effective Modern C++, Item 11).

Personally speaking, it is preferable to explicitly note that the constructors or copy operators has been deleted in the document so that it can be distinguished whether it is a noncopyable class or not. I do not know whether we can solve with EXCLUDE_SYMBOLS, but what about using it instead?

barsoosayque
@barsoosayque

it is preferable to explicitly note that the constructors or copy operators has been deleted

Hmm, I see. I mean I thought so, but didn't want to tweak doxygen config, because it's hard hehe.

I do not know whether we can solve with EXCLUDE_SYMBOLS

Not with EXCLUDE_SYMBOLS, because it's some kind of config pollution, but I can mark methods as @private, so doxygen won't generate docs for these methods.

colajam93
@colajam93
@mogemimi Sorry for too late reply. Thank you for fixing the compile error! I'll try it later (I've been little busy recently...)
mogemimi
@mogemimi
@barsoosayque I didn't know @private so I tried using it in my local repo, and it works well. That looks good!
@colajam93 No worries mate!
barsoosayque
@barsoosayque
Hi hi, I found some minor inconsistency in arguments naming in the Log class. Some methods takes channel as channelName (e.g. Log::GetLevel), and others takes it just as channel (e.g. Log::Info). It's slightly confusing to see such a difference in the docs. :slight_smile:
mogemimi
@mogemimi
@barsoosayque That's a good point. We should fix these inconsistent naming.
seongju
@Lee-Seong-Ju
hello, very sorry,,,,I joined this room to ask more questions. Feel free to tell me if you're uncomfortable.
i have 'cmake' installed but i dont have 'visual stdio 2019' i have 'visual studio 2015' so i wonder this. Dosen't the problem occur??
seongju
@Lee-Seong-Ju
And one more question.im Korean. so i want to translate to Korean.can you give me permission?
ㄴ your documents.
mogemimi
@mogemimi

@Lee-Seong-Ju Hi :simple_smile:
Pomdog requires Visual Studio 2019 because it follows the latest C++17 specification. Also, Visual Studio 2019 Community Edition is free for anyone to use:
https://visualstudio.microsoft.com/vs/
https://visualstudio.microsoft.com/free-developer-offers/

If you want to open/edit source files in Visual Studio 2015 without compilation and building, you can specify the project generator using the '-G' option as follows:

# Generate projects for Visual Studio 2015
cmake -Bbuild.cmake -H. -G "Visual Studio 14 2015"
mogemimi
@mogemimi

@Lee-Seong-Ju
We'll always welcome translations of the documents to any other language.
https://github.com/mogemimi/pomdog/tree/master/docs

Also, the old information is now on the github wiki, but we plan to move them to the above docs directory and under git repository.
https://github.com/mogemimi/pomdog/wiki

So if you'd like to contribute a translation, feel free to submit a pull request to edit markdown texts in the docs directory.

seongju
@Lee-Seong-Ju
So thank you friend.ㅠㅠㅠ
almost i proceed ,,,
캡처.PNG
but i occur problem this page last sentance
i proceed "cmake --build . --config Debug" <-
but i dont find "./Debug/HelloWorld
캡처.PNG
seongju
@Lee-Seong-Ju
and i want to play this game...so i proceed "Running the Tests"
but this same occur problem,,,,
캡처.PNG
캡처.PNG
ㅠㅠㅠ why this problem occur,,,,,
mogemimi
@mogemimi
@Lee-Seong-Ju Have you created a new "HelloWorld" project? If you have not created it yet, please refer to the following page to reference, and create it.
https://github.com/mogemimi/pomdog/blob/master/docs/Getting-Started.md#create-a-new-project

@Lee-Seong-Ju Also, now that I've simplified the build process for unit testing, can you refer to the latest documentation and try again?

cd path/to/pomdog

# 1. Delete the build directory to clean completely your compiling.
rm -R build.cmake

# 2. Pull the latest master branch using Git.
git pull origin master

# 3. Generate projects for Visual Studio 2019 to the 'build.cmake' directory
cmake -Bbuild.cmake -H. -G "Visual Studio 16"

# 4. Building projects using CMake and MSBuild
cmake --build build.cmake --config Release

# 5. To run all unit tests, use the following:
./build.cmake/test/Release/PomdogTest

https://github.com/mogemimi/pomdog/blob/master/docs/Running-the-Tests.md#build-and-run-the-unit-tests-on-windows

If the build fails, may I have your build log that contains output and all error messages?