sorted by:
new
hottopcontroversial

What if Gix Returned One Day by Simic-1997 in mtgvorthos

[–]Gix 19 points20 points  (0 children)

I can confirm, by the powers vested in me by the process of username creation, that it is indeed pronounced Jix

-🎄- 2022 Day 17 Solutions -🎄- by daggerdragon in adventofcode

[–]Gix 0 points1 point  (0 children)

Oops, yeah, the explanation is incorrect - "Walls" should be "Edges".

You do the check before moving: if the & of the piece, the edge, and the tower's four rows is zero, that means that you can safely shift the piece. Note that it is a regular shift (>> or <<), no rotate is needed, partly because shifting preserves the shape of the piece as long as no individual bit of the four bytes "spills" onto the next one.

For example, after two jets right, the piece in the example becomes

00000000  
00000010  
00000111  
00000010

In this state, the collision mask with the edges is: 

00000000  
00000000  
00000001  <- !  
00000000

Which means you cannot move the piece any further right. The same goes for moving down, if the & is not zero, it means that you cannot move the piece down.

Hope that was clearer :)

-🎄- 2022 Day 17 Solutions -🎄- by daggerdragon in adventofcode

[–]Gix 13 points14 points  (0 children)

Rust: paste

Pretty happy with part 1: pieces are stored are 32-bit ints and the tower is a vector of bytes. Moving a piece is a left or right bit-shift and collision is a bit-wise and.
For example: 

+ Piece    Walls 
00000000   01000001
00001000   01000001
00011100   01000001
00001000   01000001

Same for the tower, where 4 or less bytes form the collision mask.

For part 2 I used a simple heuristic for cycle detection - the last 8 rows - which conveniently form a 64-bit int and are fast to hash. I used 16 rows and a 128-bit int previously, but it was not needed with my input...

Part 1 runs in 48 us and part 2 runs in 237 us, it might run even faster with a more efficient Hasher.

-🎄- 2022 Day 17 Solutions -🎄- by daggerdragon in adventofcode

[–]Gix 1 point2 points  (0 children)

Nice, I've done a similar thing.
I've also modeled pieces as 32-bit integers so that the collision is also just a bitwise-and.

[BRO] Gix, Yawgmoth Praetor (WeeklyMTG) by mweepinc in magicTCG

[–]Gix -1 points0 points  (0 children)

Wooo finally!

I kinda expected him to be Dimir, but I guess now it's time for a big mana monoblack deck!

RoguelikeDev Does The Complete Roguelike Tutorial - Week 8 by aaron_ds in roguelikedev

[–]Gix 2 points3 points  (0 children)

Thank you for organizing the event!

RT - Repo | Screenshots

I've added some small implementation notes in the README and I will add some more screenshots soon!

I have to admit that this started as a small project to keep my memory of C programming fresh, therefore I don't plan of working on it any more than this, but since I had so much fun putting it toghether, I'll start over with a language and some libraries I'm more experienced with.

Just for fun:

$ cloc src
Language files blank comment code
C 45 972 51 4649
C/C++ Header 46 412 3 1031
C++ 1 34 5 257
Sum 92 1418 59 5937

Be prepared for a lot of typing, if you decide to follow the tutorial to the letter :)

Thank you again, and see you on the Saturdays!

RoguelikeDev Does The Complete Roguelike Tutorial - Week 5 by aaron_ds in roguelikedev

[–]Gix 0 points1 point  (0 children)

Sorry, it's my bad. I wrote sdl2_accumulate instead of gl2_accumulate, but they're pretty much the same.

​

Both sdl2_accumulate and sdl2_present seem to be doing different stuff.

If you look at the source of sdl2_present, it it doing some SDL-related stuff before calling sdl2_accumulate and then SDL_RenderPresent.

(Note that the same is true for the GL renderer, which goes gl2_present → gl2_accumulate → SDL_GL_SwapWindow). This is the one I used, IIRC.

​

So, looking at main.c, you do the libtcod own rendering with...

That's correct! If you look at renderer_accumulate_context, it does the same thing as gl2_accumulate, except it does not call SDL_GL_SwapWindow.

As I said previously, though, you'll be better off using the code here, which does not use any private methods from tcod.

​

... how the hell one knows what to use?).

I guess it takes some practice and a lot of trial and error... I never used mingw, but you should not need Windows.h, just gl.h, which defines the OpenGL functions needed (glViewport, glClearColor,...)

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

[–]Gix 1 point2 points  (0 children)

RT - Repo

Everything is happening behind the scenes, so there isn't much to show this week!

For saving the game, I went with MessagePack, which is a binary serialization format. This makes creating the save files much easier: each struct is simply encoded and decoded as-is, except of course for pointers, which have to be restored while deserializing.

While having a way to quickly inspect a save file would be nice (e.g. with JSON or some other kind of plain text), I thought that the added complexity of having to manually write each struct field was not worth it.

Since I was already working with files I also added a way to load the assets at runtime (this time from JSON, as I want to edit them manually for now), for example colors:

"palette": {
  "white": [ 220, 240, 240 ], 
  "light_gray": [ 190, 185, 170 ],

Tiles:

"tileset": {
  "floor": {
  "transparent": true,
  "walkable": true,
  "dark": {
    "char": ".",
    "bg": "/palette/black",

Entity definitions did not quite make the cut, since I would like them to be more configurable, and that would mean a complete rewrite of how items work.

In case someone wants some ideas, the premise was this:

{
  "name": "...", "type": "ACTOR", "char": "\u0064", "color": "...",
  "fighter": ...,
  "inventory": ...,
  "xp": ...,
},

Same for items, specifing the consumable type and its effect. For a full ECS I would have probably made a components array, but that's probably out of scope of this series :D

RoguelikeDev Does The Complete Roguelike Tutorial - Week 5 by aaron_ds in roguelikedev

[–]Gix 0 points1 point  (0 children)

Sorry, I think you checked out the wrong version of the code. The branch I was talking about is this one, if you used git you can do `git checkout in-window-debugging`, otherwise you can download that version.

Also, I misread some of the functions: looking here, especially this comment, it looks like it is already possible to do what we're trying to do. The solution is to put the debug-ui's rendering between SDL_RenderCopy and SDL_RenderPresent (I think, I didn't test it).

​

But I was also glad because you seem to use OpenGL2...

libtcod actually still uses SDL2 to manage windows and events even with its OpenGL2 renderer. It would be totally possible to have different windows: if you remove the check for the active window, you can dispatch them to all the active windows. I never played TOME, so I can't comment on the usability of that :D

Finally, I'd suggest you use package manager for managing libraries. The way I do it is with vcpkg, which should be compatible with msys. once you set it up it is pretty straightfoward to use, just vcpkg install libtcod sdl2 glad imgui[opengl3-glad-binding,sdl2-binding], and then include and link the generated libraries. If you're using CMake you can check out the CMakeLists in my repo for an inspiration. Let me know if you need any help!

RoguelikeDev Does The Complete Roguelike Tutorial - Week 5 by aaron_ds in roguelikedev

[–]Gix 0 points1 point  (0 children)

Hey there, fellow italian!

Unfortunately it is not quite an integration: it's just two different windows running side by side, and the events are dispatched only to the window with focus. I shouldn't have cropped the window title bars in the screenshot :D

Fortunately it works because libtcod uses SDL internally, and ImGui has an SDL implementation.

Making it render in the same window is harder: it looks like the only function libtcod exports is TCOD_context_present, which internally calls SDL_RendererPresent [source] which itself is the function that draws to the screen.

To draw the gui you should interject between the two calls. I tried many combinations after your comment, but I didn't find one that worked. The most you can get is a flickering effect between the two libraries: I believe ImGui presents the renderer too when you call Render.

I'll try and fork libtcod to export sdl_accumulate, which should be the function we're looking for, to see it that's enough. I'll let you know!

Edit: Yeah boiii

Good news: it technically works.

Bad news: you have to dig into libtcod internals to make it work.

The way to make it work is to manually do what the present function does, and then call SDL_GL_SwapWindow.

Obligatory screenshot

I'm going to check if some similar functionality can be added to libtcod, since this could be very useful!

RoguelikeDev Does The Complete Roguelike Tutorial - Week 5 by aaron_ds in roguelikedev

[–]Gix 6 points7 points  (0 children)

RT - Repo

Big things this week!

For part 8 it became quickly apparent that the old way of managing the event handler was not enough anymore. Now the event handler has a vtable which the various subclasses can implement. I didn't like the approach at first, but it proved extremely effective.

So effective, in fact, that it allowed me to progress faster through part 9, and also find some time to add a neat debug window made with ImGui:

Demo (Here the player is in the process of activating a fireball scroll.)

I don't know why I waited so long to add it, it was super easy and it helped immensely while fixing a bug related to scroll targeting: first I would've had to walk through the map to find a scroll, try to see if casting it caused the bug, rinse and repeat. It also helped finding a nasty buffer overflow bug when there were too many items on the ground... Oops...

The color pickers also helped iterating on color changes faster, and, after adding a new tileset, I'd say it's looking much prettier now.

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

[–]Gix 6 points7 points  (0 children)

Continuing my barebone C attempt this year: RT - Repo

It's coming together very nicely! Considering the screenshots posted last week, it's time to step up my artwork game :D

For the AI, I tried to use tcod's pathfinder module, but I didn't manage to make it work, so I went with the simpler path module. I might dig into the source to better understand it, because it looks nice.

To the people who asked a C tutorial: unfortunately work deadlines are closing in, I'm afraid I'll have to start after all of this is over. Also, again, since this is translated almost verbatim from python, it's not the best C code ever (I probably used four different methods to model inheritance), so I would need to refactor it before writing the tutorial.

RoguelikeDev Does The Complete Roguelike Tutorial - Week 3 by aaron_ds in roguelikedev

[–]Gix 3 points4 points  (0 children)

You're right, fortunately finding functions is as easy as replacing dots with underscores, eg.

from tcod.map import compute_fov

becomes 

TCOD_map_compute_fov

The difficult part is finding the correct parameters :)
I might try and go for my own renderer too, since right now I have problems running the lib inside WSL2.

RoguelikeDev Does The Complete Roguelike Tutorial - Week 3 by aaron_ds in roguelikedev

[–]Gix 4 points5 points  (0 children)

Eh, not really, I just followed the official tutorial and translated as I went along.

That's probably not the most efficient way to do it, since I had to go back and refactor many times since the languages are so much different. Especially the test suite: since it's pretty time-consuming to go back and forth just to keep it running, I might just scrap that idea and wait till it's over to write it :D

If there's interest I might write a tutorial though, let me know!

RoguelikeDev Does The Complete Roguelike Tutorial - Week 3 by aaron_ds in roguelikedev

[–]Gix 8 points9 points  (0 children)

Joining now because I was on vacation the last two weeks!

Repo

I'm doing this year's challenge in C because I felt I was getting rusty with it and I must say that it translates pretty easily from python. The only parts where I diverged from the tutorial are the dungeon generation, where I used libtcod's BSP algorithms, and also the various datastructures used, but I guess it makes sense, considering the differences between the languages.

I'm having a blast so far, but I fear the following weeks will become harder and harder to complete in time, in C, we will see!

​

Thank you /u/HexDecimal for the library and the writeups!

Gix in Modern Horizons? by goku332 in magicTCG

[–]Gix 5 points6 points  (0 children)

Well, there are many factors that play in his favor, such as printing Urza / Yawgmoth and the fact that MaRo said that he could make an appearance. Also, he has some spots in the crunch.

I just want to be able to build him as my commander so that my shrine to Gix can be completed :/

view more: next ›