Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Morgana retro Dungeon Crawler (uses Tilengine)
#31
Hello again! Finally I've been able to implement the glitch sanity effect, check it out in this youtube hidden link video!



What do you think about it? The progression is too hard or annoying? It will be disableable by the user in the options menu if it annoys the player but switched on by default, I think, to entice the user to raise his sanity with sanity potions.

I was wondering if it would be better to use 2 pixels height lines, 4 pixels height lines, and so on, when sanity worsens. What parameter should I touch, megamarc?

The progression is as follows:

Code:
int HGLITCH_AMOUNT=0;
int VGLITCH_AMOUNT=0;
int HGLITCH_STRENGTH=0;
int VGLITCH_STRENGTH=0;

// First glitch level
void primer_nivell_glitch(){
HGLITCH_AMOUNT=2;
VGLITCH_AMOUNT=10;
HGLITCH_STRENGTH=3;
VGLITCH_STRENGTH=2;
}

// Second glitch level
void segon_nivell_glitch(){
HGLITCH_AMOUNT=8+5;
VGLITCH_AMOUNT=10+5;
HGLITCH_STRENGTH=3+5;
VGLITCH_STRENGTH=2+5;
}

// Third glitch level
void tercer_nivell_glitch(){
HGLITCH_AMOUNT=8+10;
VGLITCH_AMOUNT=10+10;
HGLITCH_STRENGTH=3+10;
VGLITCH_STRENGTH=2+10;
}

// Fourth glitch level
void quart_nivell_glitch(){
int q=30;
HGLITCH_AMOUNT=8+q;
VGLITCH_AMOUNT=10+q;
HGLITCH_STRENGTH=3+q;
VGLITCH_STRENGTH=2+q;
}

// Fifth glitch level
void cinque_nivell_glitch(){
int q=50;
HGLITCH_AMOUNT=8+q;
VGLITCH_AMOUNT=10+q;
HGLITCH_STRENGTH=3+q;
VGLITCH_STRENGTH=2+q;
}
Reply
#32
By the way, thank you very much for your help on this one. I couldn't have figured it out on my own without your help! Biggrin
Reply
#33
Hi Jaume!
Nice integration, glad to see you have it already working :-)
I don't think it's annoying at all, however my personal opinion doesn't matter as this is an aesthetic choice related to game design. It's best to beta-test the game ang get feedback from testers.

One question: the effect of the background "jumping" over the top part of the window is intentional or a bug of the implementation of the glitch? It feels a bit strange because the glitch gets contained by the other three sides of the window, feels somewhat broken. Just an opinion.

Regarding thicker lines, they can be achieved but not just by tweaking a parameter, the algorithm must be modified a bit. In make_glitch_map(), when determining that a line must be glitched, following n lines must be loaded with the same value, and c must be skipped by the same amount. For example for 3 pixels thick lines:

Code:
        val = rand() % 1000;
        if (val < HGLITCH_AMOUNT)
        {
            glitch_map[c] = -HGLITCH_STRENGTH;
            glitch_map[++c] = -HGLITCH_STRENGTH;
            glitch_map[++c] = -HGLITCH_STRENGTH;
        }
Keep the good work!
Reply
#34
Hello! Thank you for the help megamarc, and sorry for the delay, I've been programming other things but I'll return to the glitch sometime. The glitch jumping over the top part of the screen was unintentional and I think I've fixed it somewhere, I'll check that out, noted.

Meanwhile, here it is another promotional screenshot for our game!

[Image: doble-res.png]

Quote:Homage to 'All is Vanity' by Charles Allan Gilbert, 1892 (https://en.wikipedia.org/wiki/Charles_Allan_Gilbert). Art & art direction: Mrmo Tarius (http://pixeljoint.com/p/7846.htm). Design & Programming: Jaume Alcazo (jaume.alcazo@gmail.com). This inventory icons: Caz (https://cazwolf.itch.io/) & Cyangmou (https://cyangmou.itch.io/). Programmed with C, SDL & Tilengine (http://www.tilengine.org).

Best regards.
Reply
#35
Hi!
Thanks for the feedback, I hope you're doing well.
Pixel art of your game is gorgeous! Very nice
Reply
#36
Hi there!

Sorry for the long delay in updates. I had periods of inactivity and rebooted the source code development, porting it from C to C++.

Port is going well, except for a very insidious bug.

I have no memory leaks, because I switched all raw pointers yo shared_ptr's. I analyzed the code with CppCheck and corrected some issues. I will do more g++ checks such as the -Weffc++ option and others.

But let me explain, maybe you have some idea. Everything works fine, you start walking and navigating the labyrinth, all works fine for a while but it progressively slows down. You walk slower and slower, and when you bump on a wall the animation that pops up is each time slower.

This continues until the game crashes.

Maybe I spawn Tilengine sprites somehow and they draw on top of each other unnoticed. Hmn.. There's not a function of Tilengine to check the number of sprites used? GetNextAvailable can return low values, its not a substitute for getting the total of sprites used by the engine in a given moment.

It is an accumulative error, because if I start the player at the other end of the labyrinth, where it crashed the last time then everything works fine until you walk too much. For solving this problem ideally I think I could print each frame: "number of sprites used: xxx" and check how it accumulates over time..

Hmn.. I think I will have to dissect the code carefully to see where the drawing function leaks or bleeds and what causes this accumulative problem. What do you think megamarc from your perspective? If an animation works fine in your engine and after a while it plays slow, what could be stressing the engine? Just the number of sprites used, right?
Reply
#37
Can I send a video of the problem to you, privately, megamarc? Gmail? And I will send you an mp4 by Google Drive.
Reply
#38
Hey I think I found the problem!
Reply
#39
Video 
Check out this vid.



I initialized the engine with: TLN_Init(width,height,10,1000,50);

So, 1000 sprites limit.

Everytime I walk (offscreen) you can see sprites accumulating.

Well, now I'll put this elsewhere to try to find the culprit: cout<<"Next available sprite: "<<TLN_GetAvailableSprite()<<"\n";
Reply
#40
Ok, it's the GUI covers not getting cleaned.

I'm embarrassed.  Dodgy

At least I solved it by myself! Smile

Well, back to work..
Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)