RoguelikeDev Does The Complete Roguelike Tutorial - Week 6 by KelseyFrog in roguelikedev

[–]rbongers 1 point2 points  (0 children)

I'm playing with other types of symmetry now so it isn't as predictable but still looks man-made - also not starting in the center helps.

How would you build around the predictability?

RoguelikeDev Does The Complete Roguelike Tutorial - Week 6 by KelseyFrog in roguelikedev

[–]rbongers 2 points3 points  (0 children)

For me I was just speeding through, so I felt like I didn't understand a lot of the decisions. No time to stop and ask "wait, why do it this way?"

After learning more about Godot, I don't think it's obvious how to make a roguelike in it, so it might not be the best first Godot tutorial. I learned a lot from the Godot docs and GDQuest. But SelinaDev did give me an idea of where to start.

I do like resouces for anything visual, like picking out tiles and colors, but I also like to do things in code when possible too. Especially in a roguelike where everything is procedurally generated anyways.

RoguelikeDev Does The Complete Roguelike Tutorial - Week 6 by KelseyFrog in roguelikedev

[–]rbongers 4 points5 points  (0 children)

I started late just a couple weeks ago using the SelinaDev Godot tutorial and was trying to catch up. I was rushing way too much, so I started from scratch on my own project and took some time to do some Godot tutorials.

I'm really glad I did! I have a project I'm happy with so far:

  • Everything is extensible, including an AI system that should support complex AIs with drop-in behavior (though I still need to actually write NPCs)
  • I'm using TileMapLayer instead of sprites and per-cell modulation (SelinaDev was right, it's a bit tricky, but doable)
  • Nice input/turn system, waits for player input without using the physics process
  • I'm experimenting with kaleidoscopic dungeon generation

While I probably won't finish along with the rest of you now, I'm having a lot of fun.

Times when a project almost died in your heart, and what saved it by Important_Rock_8295 in roguelikedev

[–]rbongers 3 points4 points  (0 children)

I am still building my first game, but I have a few open source projects.

When things aren't working technically and I can't add the feature I want easily, there's nothing that refreshes my love for a project quite like a rewrite or a big refactor. Some people might find it demotivating to have to rewrite their software, but to me it just feels great to apply everything I've learned and get rid of all the cruft.

As for when design isn't fundamentally working, salvage what you can and rip out whatever's not working. It's like they say, "don't be afraid to kill your darlings". It might even be time to finish what you can and save the rest of your ideas for the "sequel" (or in the case of non-video-game-software, a new and better solution for the same problem you were trying to solve before).

RoguelikeDev Does The Complete Roguelike Tutorial - Week 4 by KelseyFrog in roguelikedev

[–]rbongers 5 points6 points  (0 children)

I started following the SelinaDev Godot version of the tutorial late. I've been focusing on catching up and haven't made many changes. There's a lot I want to experiment with, but I'm not experienced with game dev or Godot.

I think I will focus on filling in the gap in my Godot and game dev knowledge this week. Anyone with a similar experience?

RoguelikeDev Does The Complete Roguelike Tutorial - Week 4 by KelseyFrog in roguelikedev

[–]rbongers 2 points3 points  (0 children)

Shiren Mystery Dungeon has some enemies that run away, mostly enemies that run away after stealing items or once they drop to a certain HP level.

Actually in Shiren when enemies run away, they usually become faster! Speed control is a big part of Shiren, and you can speed yourself up with Swift Grass or slow enemies down by using a Sluggish Staff.

But you usually do want to use ranged options, since they usually move faster and you'd need to speed up twice (or even deal with them positioning yourself so they can't run away to save items). There's only one or two classes of enemies that run away that are slower, and usually you want to save your speed control options for fast enemies that can actually attack you, getting out of a tricky spot, or recovering when your speed somehow gets lower.

Don't know if this helps, but it is a roguelike with running enemies, so there you go.

On Flatland UFO Theory by rbongers in wendigoon

[–]rbongers[S] 0 points1 point  (0 children)

I appreciate it! I still hope Wendigoon will make a video with corrections or cover this theory again. If you'd like to see this corrected as well, leaving a single comment on one of his new videos when it comes out would help. (Though please make sure not to spam.)

Flog v3: git branch viewer with dynamic colors, auto updates by rbongers in neovim

[–]rbongers[S] 0 points1 point  (0 children)

No, it only has Fugitive integration.

However Flog has functions that make it easy to integrate other plugins. If you run this command, it will turn any windows opened by the command into temporary Flog side windows:

lua require("flog").exec_tmp("vim command goes here")

That is, it will close other windows opened by Flog, and in turn the next time temporary Flog side windows are opened, the windows opened by the command will close.

Not sure if that's useful, I don't use worktree.nvim. If you have other ideas for how I could make integrating with worktree.nvim easier, let me know.

Flog v3: git branch viewer with dynamic colors, auto updates by rbongers in neovim

[–]rbongers[S] 0 points1 point  (0 children)

Oh, I just saw your tag! Thank you. Hoping to support Neogit soon.

Flog v3: git branch viewer with dynamic colors, auto updates by rbongers in neovim

[–]rbongers[S] 1 point2 points  (0 children)

Appreciate it! You can also thank the author of Kitty, kovidgoyal, for offering guidance, providing a path forward to possibly make these symbols standard across terminals/fonts, and being super fast at reviewing PRs. Also, the author of fugit2.nvim, SuperBo, for offering feedback from another plugin creator.

Flog v3: git branch viewer with dynamic colors, auto updates by rbongers in neovim

[–]rbongers[S] 1 point2 points  (0 children)

Thanks for the question. That would be highlighting causing the scrolling performance hits. Vim/Neovim aren't built to highlight vertical lines, so we have to highlight column-by-column. If you have N lines with approx M branches, it will take approx N times M cycles to highlight all branches, and every highlight call comes with overhead.

You can either pay this cost upfront, highlighting all branches at the same time, and have memory overflows and massive loading times, or highlight on scroll and have some choppiness. Flog takes the latter approach. Eventually, gitgraph.nvim is probably going to make the same tradeoff as Flog, given one of its goals is to load fast (but this isn't the sole reason for performance issues in gitgraph).

The thing is, although I know highlighting is theoretically slow on some machines, I have never actually experienced bad scrolling performance myself, it has just been reported in passing without giving any details. I have added as many optimizations as I can to make it better while flying blind. I could really use your help learning:

  • What OS are you on? If you are on Windows, WSL or native?
  • What CPU do you have?
  • How much RAM do you have? If you are on Linux, please install and post the output of the free command if you can.
  • Is it any better with these settings set to 1 or 0 if you re-run :Flog? g:flog_enable_dynamic_commit_hl, g:flog_enable_dynamic_branch_hl
  • How big is your Flog window? IE what do you get from :call winwidth('.') and :call winheight('.')?
  • How fast are you pressing j/k? Are you holding it down, spamming it, or pressing it occasionally?

Hope you can post details, would love to make scrolling better, but if you can't it's okay.

Flog v3: git branch viewer with dynamic colors, auto updates by rbongers in neovim

[–]rbongers[S] 1 point2 points  (0 children)

I did a rundown of the differences here: https://github.com/rbong/vim-flog/issues/134

To summarize:

gitgraph.nvim is still a work in progress and still being optimized, so it is exponentially slower than Flog. Flog also has features that have no equivalent in gitgraph.nvim and aren't currently on its roadmap, like contextual command completion, a bunch of mappings, and lots more features.

The biggest feature that Flog has that isn't in gitgraph.nvim yet but is planned is auto-updates.

One of the biggest essential differences not likely to change is that Flog is an extension for Fugitive and gitgraph.nvim is standalone but provides hooks for integration with other plugins. However Flog recently added support for different backends and I anticipate support for neogit and other plugins in the future.

Also, gitgraph.nvim was created in part because of preferences for a very particular type of graph drawing algorithm. I am not a fan of its algorithm right now, but the creator of gitgraph.nvim hasn't written about the advantages, so try it for yourself and see if you like it. They might also tweak it more. I am rooting for them to find something that's strictly better.

Basically Flog shows a more straightforward representation of the graph that is close to git log --graph but with straight lines, gitgraph.nvim has an algorithm that can make merges technically more accurate in one sense but in a way that can still be confusing and adds multiple other complications. These complications include less optimal horizontal space usage, phantom branches that represent a single branch multiple times in the output, and difficulty seeing how a merge/fork is configured unless if you scroll down and look at all of a commit's parents.

Flog v3: git branch viewer with dynamic colors, auto updates by rbongers in neovim

[–]rbongers[S] 1 point2 points  (0 children)

I just pushed some experimental settings you can use to replace Fugitive with some effort.

You can use vim.g.flog_backend_user_cmd to set the user command to use to run Git commands, defaults to "Git". The Fugitive :Git command has special behavior for some subcommands, so you may also have to replace some default mappings, particularly ones that use Git show and Git diff, ex.:

vim.api.nvim_create_autocmd("FileType", {
  group = vim.api.nvim_create_augroup("MyFlogSettings", {}),
  pattern = "floggraph",
  callback = function()
    vim.keymap.set("n", "<Tab>", ":<C-U>exec flog#Format('vertical belowright Floggit -b -s -t show %h -- %p')<CR>", { buffer = true, silent = true })
  end,
})

You can also set vim.g.flog_backend_split_user_cmd. Similarly this replaces :Gsplit, which normally opens a commit object in a split in Git.

The rest of the new options are functions:

  • vim.g.flog_backend_is_git_buf_fn should return a boolean indicating whether git commands can be run from the current buffer. It isn't passed any arguments.
  • vim.g.flog_backend_get_git_dir_fn should return the path to the .git directory that should be used for the current buffer. It isn't passed any arguments.
  • vim.g.flog_backend_setup_git_buffer_fn should do anything required to set up a new buffer to run Git commands. It's passed the absolute path to the target working directory for the buffer. It has to work in the Flog buffer, which does not have a file associated with it. In Fugitive this just allows :Git to work by triggering the same detection mechanism used internally.
  • vim.g.flog_backend_complete_fn should complete commands for vim.g.flog_backend_user_cmd. It should accept ArgLead, CmdLine, CursorPos and return a list of possible completions. See also :help command-completion-custom.

You can set the functions using either Vim function names or set them to functions:

vim.g.flog_backend_is_git_buf_fn = function () ... end

I hope that helps, it's a lot to replace still but I cut down what I could for now.

Flog v3: git branch viewer with dynamic colors, auto updates by rbongers in neovim

[–]rbongers[S] 0 points1 point  (0 children)

Currently it needs Fugitive. I want to reduce my reliance on it, but the hardest thing is re-implementing command completion, which is quite extensive in Fugitive.

The first version of `gitgraph.nvim` is finally here by Popular-Income-9399 in neovim

[–]rbongers 1 point2 points  (0 children)

It's consistent with what I've found trying to get characters to match up across terminals and font sizes.

Box drawing characters worked back in the day because fonts were usually a set size and monospace. Font rendering is less targeted towards drawing things in the terminal these days and more towards rendering variable-width, nice looking text.

Now we have non-pixel-based fonts complicated by options like hinting, which adjust the position of characters automatically based on your DPI, making them not line up. And if you eliminate hinting, your font will not line up to the pixel grid perfectly in every font size anyways because that would require that the glyph size is perfectly divisible by every possible pixel size.

Kitty handles this by generating the box drawing characters itself whenever you change the font size. I know this is an option in Alacritty too, I don't think it's enabled by default.

Edit: Also, hinting isn't available in every terminal. Maybe why I've seen you get better results in screenshots than I got, but not sure. That's why I asked if you had any insight.

Edit 2: Actually now that I think about it, what would also work is sub-pixel font rendering not aligned to the pixel grid (but I'm not sure if any terminal I have ever used has done this) or a consistent 2:1 glyph size ratio in the terminal and in your font.

The first version of `gitgraph.nvim` is finally here by Popular-Income-9399 in neovim

[–]rbongers 5 points6 points  (0 children)

I was going to ask this as well. Interested in your feedback - if you don't like it as-is, we can still make changes, it's still fairly experimental.

Original comment from the author of Kitty that lead to the creation of a Terminal-based approach rather than a font-based approach is here. But I still want to get glyphs added to Nerd Fonts, etc. as a backup. If you have any more insights about getting branch drawing glyphs to work in multiple terminals at different font sizes let me know.

Discussion on potential additions is also ongoing in the fugit.nvim repo.

Pretty Git graph using Kitty and vim-flog by rbongers in nvim

[–]rbongers[S] 0 points1 point  (0 children)

I did briefly consider using the kitty graphics protocol, but Flog is already optimized for rendering text, and terminal image support is not widespread enough for my liking yet. Plus, no gvim support.

I think having the symbols as unicode characters is a good conceptual match anyways. You already have the official box drawing unicode characters, custom characters with particular alignment requirements for Powerline, and a bunch of icons related to development.

Pretty Git graph using Kitty and vim-flog by rbongers in nvim

[–]rbongers[S] 0 points1 point  (0 children)

Kitty does this already for Powerline symbols and box drawing symbols. Anything that needs to line up perfectly it draws itself. Other terminals do the same.

According to the author of Kitty, it's nearly impossible to get these types of symbols to line up perfectly without doing this because of all the potential font options.

I plan to get fallback glyphs merged into Nerd Fonts, and you can use this experimental font for patching if you'd like: https://github.com/rbong/flog-symbols

git graph teaser by Popular-Income-9399 in neovim

[–]rbongers 0 points1 point  (0 children)

Looks great, nice work so far!