New to Fuse4-want a Faery Tale Adventure like game

xevdev

but i cant see anything yet that is that problematic in this code (old code) yet. So its interesting in that all of the code I've written never crashes like this.

tdg8934

@xevdev

I’m almost sure I have this figured out to be too many c=control(0) statements where there should only be 1 in a loop.

The character selection blue screen uses it along with MenuPress() and CharacterWalk() functions.

xevdev

@tdg8934 hopefully yes. I once tried something like that. In another thread somewhere I'll look.

xevdev

https://fuzearena.com/forum/topic/804/crashing-what-did-i-do
This is it

xevdev

And you should check out saharamins reply at the end I use this and it's awesome.
https://fuzearena.com/forum/topic/645/any-way-to-hide-this-mess-of-initialisation-code/6

tdg8934

@xevdev SUCESS - NO CRASHES !!!

Following Sahara-Min method:
“
function main()
// Program starts here
return void

// Other functions...
// Variables...

main()
“

See the working crash free (WIP) FTA like game:

ID: Z7573MND51

From now on I will always use this program layout.

Thanks so much especially @xevdev and @sahara-min

tdg8934

All,

I have made some great updates to the (WIP) - FTA like game

Updates:

Fixed logic so when you find objects they are removed not going into the abyss
Have N S E W NE SE SW NW and Home teleport locations (Use if you have a travel stone)
24 hour day over 1800 seconds (Set it to what you want but it might get dark sooner)
Green jewel night vision capability
Bird totem zoom out capability
Find object- keys, jewels, rings, jade skulls, orbs, glass vials, bird totems, money bags, treasure chest
Coins (find money bag)
Use Glass viaL to increase vitality
Help menu

Plus previous stuff - all crash free!!!

What’s not working yet:
Keys, orb, ring, jade skull, sea shell
Creating bad guys to fight
Creating landscape, water
More...

ID: Z7573MND51

tdg8934

Update on the FTA (WIP) game!

‪FTA ‬
‪ID: Z7573MND51‬ (Live)

For all that are following this game development. I’m now over 8K lines of code still with no crashes.

I have been focusing on going outside of the home village of Tambry. You can teleport to 9 locations (if you have a bird totem). There is now a cemetery when the character can also fight to the left or right now. The grim reaper is inside of the crypt and will give you a gold statue if you come back after midnight. If you continue south and then to the right along the paths (note teleport stations). You will find the capital city of Marheim where the king is at. His daughter is missing. Lots more to see and do but not going to give away too much yet. See the pics ![alt text]( image url)

xevdev

Looking really sweet.

tdg8934

@xevdev yes I’m pretty happy with it . I just can’t believe how much work is involved in the details. I love spending every free minute I can on it daily. I have learned so much on this project being my first Fuse4 program.

xevdev

Addicted like me.
I like how you've kept on going because there is a lot of details in every game and that's where you learn to code. I love the puzzle of it all too.

tdg8934

@xevdev I’ve been able to get 5 enemies to come out (no weapons yet). They can walk towards the main character and keep some distance between all of them. The main character can collide his weapon into the enemy and the visibility is set to false (ie killed). One issue is the main character uses c=controls() but the enemies move toward the main character from random locations but they are always in a running/waking animated mode (no idle stance) that I can’t seem to figure out yet. It’s looking great so far.

tdg8934

I did a lot of code cleanup and added in a user interface coding from Gothans Rubics cube Fuze4 program. Also focused on the title screens . Sorry the lighting wasn’t great for the time of day on my tv. Gotham

vinicity

Looking good, Tim!

PickleCatStars

Yeah, it totally is!

Z-Mann

Good luck! This was one of the first games I played on my own computer, so it has a special place in my heart. Don't forget to include the secret of mysterious Pixle Grove! (Going by the ingame spelling)

You should probably spend some time on removing code duplication, though. I haven't looked too closely, only had a quick scroll through (the version from two days ago or so), but are you handling each item in the world in its own bit of code? If you continue that, you'll go mad. The code editor is slowing down already, that's only going to get worse as the file grows. Code cleanup isn't sexy and it's tempting to put it off for later, but in my experience (outside of FUZE), it's best do do it as early as possible.

tdg8934

@Z-Mann thank you for the insight. I’m not a programmer so I tend to do things as I think of them. It has definitely been driving me crazy but I’m drawn to it.
I was figuring out how to deal with all of the landscaping (plants, etc) hoping I could make them into sprites and randomly lay down a few million of them but that caused memory array issues. But the worst was the more I add, it seams like the NOTE FREQ music seems to slow down. I then thought of making plants into Images but all that happens is that they float on the main 1920x1080 window as the character walks. So it looks like I’m going to have to use the map editor and just click all over the grass. I did that and got the character and enemies to slow down at random speed differences so that worked. But the larger this program gets it makes me wonder about the effort in the landscaping and being worth it. Yes grass and villages and mountains and castles are ok but it’s already over 10k of code lines to scroll through. The enemies don’t really fight yet but they do swarm around and get near the main character. I can kill them by running back and forth into each one 5 times when they drop a random item for me to pick up.
I also had problems getting arrays to transfer with functions too so I went back to how it is now.

I just shared the latest copy:

‪FTA ‬
‪ID: Z7573MND51‬

Z-Mann

I haven't used images myself yet and the documentation is not super clear, but could it be that the coordinates you give to drawImage are just screen coordinates? With sprites and maps, any coordinates you give them are modified by the sprite camera postion. So when you want to draw images in specific world positions, you may need to place them at {x - centerPoint.x, y-centerPoint.y}. That's what I would try, anyway. But: stick to sprites and maps. The huge advantage of sprites is that Fuze takes care of not wasting time on offscreen sprites for you. Slowdown only crops in between 5000 and 10000 sprites. I'd be surprised if the map system would perform worse.
To make the map less tedious to fill, you could define your own huge grass image (like four screens big) and use that as background over and over. That would only need repeating... 4250 times. Err. You'll need to either shrink the map or divide the world between several maps, it seems.

Speaking of the sprite camera postion: You should do drawMap() after setSpriteCamera(). The way you do it now, the old sprite camera position is still used for the map, so the map scrolling is one frame behind the sprite scolling. The visible effect is that as you change walking direction, the sprites seem to wobble back and forth on the ground.

A little push in the right direction against code duplication: Around line 1730, you're distributing the items randomly. You can simplify that:

function RandomizePositions(ref sprites)
positions = []
 for i = 0 to len(sprites) loop
  rx = rnd(range1)-range2
  ry = rnd(range1)-range2
  positions[i] = {rx, ry}
  setSpriteLocation(sprites[i], rx, ry)
  setSpriteVisibility(sprites[i], true)
 repeat
return positions

Key caveats are that while you can modify array elements of an array you pass in via 'ref', you can't currently extend the array. So the options to fill the positions array are to either pre-allocate it to its correct length before passing it into the randomize function by reference, or just having the randomize function return it. Returning it is easier.
Then you can position your white keys with

p2white = RandomizePositions(keywhite)

and the other items accordingly. Extra randomization, like the bag contents, still need extra care, obviously.

tdg8934

@Z-Mann and others,

I was able to clean up alot of my code in sprite duplicate areas for 10k lines down to 7k without even looking at the enemy coding yet so that’s a huge improvement!

However I’m still seeing the Game and music playing slower for some time now. When Map1 is loaded the FPS drops from 60 to less than 30.

Since the original Faery Tale Adventure game had 17k screens that were 256x256 which equates to 1.1 billion screens. (It’s hard to believe over a billion screens were created by hand with 16x16 tiles)

Map1 which only covers a small portion of the original game (Tambry, graveyard, marheim, teleportation, walking, etc) is ~ 86,000 x 44,000 which is 1,824 (1920 x 1080) screens. If the original games 1.1 billion (256x256) screens were divided into (1920x1080) screens that would be 57,456 screen so currently my too large 1824 (1920x1080) screens would need to be 31.5 times more maps.

As it appears my configuration would need much smaller and higher quantities of maps to keep the frames per second up towards 60, I believe will need to scrap my Map1 and try to figure out what screen size would keep my FPS high.

If I load a blank map (map graphics are gone but game operates normally with sprites present running normal. It’s showing with Map-Blank loaded 1686 MB at 60 FPS. However with Map1 (map graphics are all there, ie houses, grass, teleported) but has 30 FPS and 1431 MB size playing slowly.

Thoughts on this?

Thank you - Tim

Z-Mann

To make the music play at constant speed no matter the FPS, you need to incorporate the measured frame rate into account somehow. The length in second of the previous frame is returned by deltaTime(). Care needs to be taken: it will not be exactly 1/60 if you hit 60 fps and 1/30 if you drop to 30 fps. Even in the best case, it is going to fluctuate a little around 1/60. The playback code should cope with that.

What I tried, and it worked, is to modify the playMelody function near the bottom. Before it, I declare a global variable:

melodyRemainder = 0.0

And in the body, I replace

melodyTimer += melodyTempo

with this:

melodyRemainder += deltaTime() * 60              // take into account actually passed time
melodySteps = floor(melodyRemainder)             // take only integer part
if melodySteps < 1 then melodySteps = 1 endIf    // advance at least one step
melodyRemainder -= melodySteps                   // keep balance for next frame

melodyTimer += melodyTempo * melodySteps

If you hit 60 FPS, even if deltaTime fluctuates, melodySteps will be 1 almost all of the time, so no change. And if you hit 30 FSP, deltaTime() will be about 2, so will melodySteps.

Or, if you prefer it to be simpler, you can omit the melodyRemainder variable and just do

melodyTimer += melodyTempo * deltaTime() * 60

This might even be better, depending on how sound and video output interact timing wise. Go with the simpler version first and switch to the more complicated one only if the simple version doesn't work for you.

Regarding the map: Make sure it is really the map rendering. Just because you jump from 30 to 60 FPS if you disable it says nothing; maybe the map rendering takes 1 ms and the rest of your main loop takes 16 ms, just fast enough to allow 60 FPS, and the map rendering just pushes you over the edge. You can test that by not removing the map rendering, but replacing it with

sleep(0.008) // 8 ms of sleep

If you still get 60 FPS with that, you know the map rendering takes more than about 8 ms and yeah, you'll need to do something about that.
But if you drop to 30 FPS, you know the rest of your main loop takes more than about 8 ms and that's where you're more likely to find improvement opportunities.
You can play with the 0.008 parameter to get a better feel for where the problems lie.

If it is indeed the map rendering, there would be one way to deal with it without splitting the map. Instead of rendering the map to the screen, you render a section of the map, say of size 3x3 screens, into an image. That image is then what you render to the screen. Since it is larger than the screen, you can scroll around in it quite a bit before you hit the edge; until you do so, you do not have to refresh it from the map. Of course, every time you do have to refresh the image, there will be a short, but noticeable, pause. And any chance to maybe put sprites behind map objects is lost. I'd just split the map up, I think.
(Well, no. I would try to implement the metatile system, fail miserably and give up.)