Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert codebase to C++? #153

Open
tehKaiN opened this issue Mar 19, 2022 · 2 comments
Open

Convert codebase to C++? #153

tehKaiN opened this issue Mar 19, 2022 · 2 comments

Comments

@tehKaiN
Copy link
Member

tehKaiN commented Mar 19, 2022

Most ACE utils/managers are having create/destroy functions, so this could be constructors. Also, some things that will be possible in C++ and aren't in C:

  • blitter as a global object - setting regs via method chaining, also add some helper methods. Should be able to make blitter usage a lot easier while also allowing to strip some of current blitter fns bloat/limitations without making code too messy
  • constexpr most of constructors
  • templated stuff - abiltiy to have byte- or word-indexed tilebuffer without duplicating the codebase
  • optimize stuff here and there with std::move
  • better memory management - ability to have static allocation for most of things instead of current dynamic-only approach. Should allow compiler for more optimizations. Done with either constructing globals for static alloc or using new/smart pointers for dynamic alloc
  • template most of helper fns so that they can be better optimized

Things to figure out:

  • what C++ features to use and what to skip to prevent machine code and memory bloat or general slowdowns
  • which compiler to officially support - Bartman's offers more recent C++ standard but has no STL/stdlib, Bebbo has those and optimizes better in some cases but doesn't support bleeding edge C++ and it's getting older with each day
  • should the C++ be just a wrapper for C code or rewrite it in-place? Some people may want to use C flavor
@timfel
Copy link
Contributor

timfel commented Mar 19, 2022

while on a high level i would like to see that, I'm afraid given how few people work on the optimisation pipeline for 68k in gcc, the performance impact for c++ features that have not been optimised in the 68k backend may be noticeable

@tehKaiN
Copy link
Member Author

tehKaiN commented Sep 26, 2023

From discord discussion:

I kinda need having a tilebuffer draw tile callback to draw stuff over the tile, and that gets in the way of tileBufferContinueTileDraw().

So I'm thinking - I guess we need a flag which tells the tilebuffer whether it can optimize draws this way or not, and I'm thinking whether it should be a tag in tilebuffer or a define similarly to how bob system has its feature locked. Adding ifs in bob system proved to be adding noticeable slowdowns of it could/would be the same here. In cpp world, tilebuffer could be templated and that could be one of template params setting constexpr static field, which could be then constexpr-if'd in code.

EDIT: nevermind - it first batches draws, and then calls callbacks after all tiles are drawn. Nevermind then. But being able to constexpr-specify options would probably open up some performance optimizations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo later
Development

No branches or pull requests

2 participants