Creating a fully fledged rpg battle system is a big task - certainly not something I would recommend for beginners. At first I typed out something which might get you started but it was quite a lot and I decided not to because it was too much complex information all at once.

I would recommend shrinking down your goal - if you want to make a battle system, you should create a very simple one first. Perhaps just 2 characters. You play as just one. It is either your turn or the computer's turn. Then the computer can pick a random attack for the enemy to do.

Even this is really quite a bit more complicated than you might think.

The best thing to do would be to build it slowly, piece by piece. Get 2 sprites on the screen at first, try to get a menu which you can select from.

There was a pretty good thread a little while back about menu systems - feel free to use the code I posted. You can find the thread here: https://fuzearena.com/forum/topic/1910/menu-system-program

Take it one step at a time and do not worry yet about making a fully working game. It will come in time, with patience!

Finally, I couldn't wait and chose the fastest solution, I created a separate array to check if the slot was free or not. It works ! It reassures me because I was not sure that there were no other hidden problems.

The short answer is no there isn't. However there are a couple of ways to get around that limitation. The 3D 'terrain' object is unique in that you can assign color and height values to the vertices. Some people have been able to make simple low res textures with this object.

However if you want to take advantage Fuze's 2D image assets, 2D image editor and powerful image processing capabilities, you have to do everything in the 2D graphics mode. This means you must effectively make your own 3D engine. This is possible using functions like drawQuad() which allow you to draw a rectangular image with the corners at arbitrary positions. However there are various problems. drawQuad() does not use a depth buffer and does not use 3D perspective correction.

I shared a simple example of a rotating textured orthographic cube:
Texture Map Demo
ID: NX2H21QD9L

You can get a perspective scene if you limit rotations and draw walls and floors in strips which are at the same distance from the screen/camera. The classic technique of figuring out which wall is the closest and drawing that one is called ray-casting:
https://fuzearena.com/forum/topic/922/ray-casting

As time has gone on I have expieremented with various techniques most based on orthographic projection since I can draw a whole face in one command rather than looping over strips.

In 'Jump a Face' ID: FUZEGJ0103 I changed the direction of the loop over the blocks so that they would draw in the right order. The sprite has to be positioned on the the same grid as a block tile or parts of it might not draw in the right order.

In 'Green Whale' ID: NXKKCGYD9L I used a binary space partition tree (BSPT) which is a data structure that can determine the correct draw order for polygons. However to do this it has to be able to cut faces into pieces occasionally and this is expensive and complicated.

In 'Mud Rover' ID: RS763MND9L I draw everything as a stack of 2D images ontop of each other as a 3D (voxel) bitmap. To do this I manually associate a light reflection normal with every pixel or voxel. I also have to limit rotation to a narrow range to keep from being able to see through the gaps in between the layers.

Most recently 'SCULPTURE SURPRISE' ID: NTV1VMND9L I also draw a 3D (voxel) bitmap as stack of 2D images. However I have 3 different stacks (1 for each axis) so that you can rotate around without ever seeing a gap in the volume. Additionally I have a method that automatically computes the 3D light reflections using sophisticated image processing that works directly on the images without needing to know the geometry of the objects they represent.

@n_yohan said in How to convert from sRGB to FUZE Linear RGB:

I found an online calculator http://davengrace.com/cgi-bin/cspace.pl. If you put the sRGB values on the first line, the third line (sRGB [0,1]) will have the linear RGB values. The second line is the non-linear (just dividing by 255) but you don't want that.

In case anyone else needs this, this link works better than the one posted above:
http://davengrace.com/dave/cspace/

I gave this a look and I found an easy improvement as it is now is to increase the node capacity to around 9 or 10. It seems to perform much better than 3. After that it starts to bottleneck somewhere else.

i think switch has HW FPU so doing integer maths or floating points does not show that big a off a difference as it would on systems using softfloat where fixed point math would help in that case (represent floats in integers and do calculation using the integer representations so that your not doing floating point maths but integer maths which is faster) and even if it does not it's got plenty of speed. It's not like your developping for some 200mhz device without floating point unit about 20 years ago i had such problems with gp2x but fixed point maths fixed that. But fuze will probably slow down more from doing lots of small (self written) function calls (depending on use case or when trying todo fixed point math) than doing floating point maths directly

edit: according to wikipedia switch uses tegra chip and ARM Cortex-A57 which has hw FPU

also you can easily time stuff using time() function and do little benchmarks, if you really want to investigate for example time 10000 or even 100000 time doing integer division and then do simiar using floating point division and compare times. Doing a single division will not give accurate results to compare as it completes way too fast to measure

T = Time() Do Some things you want to benchmark Printat(0,0, Time() - t)

@Slydog I did a bunch of digging into this-- you need use "matrix math" to calculate the projection. There's a whole Wikipedia article about it. One article had a painting of a guy from the 18th century or some crazy thing (wish I could find it), drawing a string through a wooden frame, explaining to someone how to do that math-- it was fascinating to me that this concept predates computers by hundreds of years!

https://en.wikipedia.org/wiki/3D_projection

@petermeisenstein Ok sounds good.

@LinkCraft You did enough :) Now I'm messing with my good ole friends "sin" and "cos", trying to get player movement to work after I invoke "setSpriteCameraRotation"... but that can be another post some other day, if I can't figure it out.

I originally wanted to use a mix of 2D and 3D for this, with polygonal walls and sprite actors-- but I gave up at the matrix math "convert 3D to 2D coordinates part".

Enough rambling :D

I've heard there is an old and unsupported Windows version that you can download on https://www.fuze.co.uk/download-fuze.html if you create an account on fuze.co.uk.

I've never even tried it, because as I understand, it's old and not on the same level as the newer FUZE4 Nintendo Switch.

They have the following disclaimer on the page after you log in:

​WINDOWS VERSION
Please note - we are working on a new version called FUZE4 Windows. The current version has problems on some Windows installations but we do not have a solution for this. In some instances running as Administrator resolves the problem.

I must say that I feel like this is not really the place to elaborate too much about other available options to create games on the Windows platform. But it's not hard to find out about them.

edit:
Another disclaimer on the page I referred to:

IMPORTANT

This is an old version of FUZE (FUZEBASIC) - It does not represent in any shape or form the new FUZE4 series which has recently launched on Nintendo Switch. FUZE4 is a total rewrite and is quite simply, far better in every way. It will also release on Windows next year.

So that's all not really encouraging to install that on my pc.

It wouldn't hurt to create all the sprites up front as long as you don't end up exacerbating things by needing too much logic around finding the next free sprite because you could quickly find you're losing performance there. As you say, maintaining a simple int that says which is the lowest free sprite index is probably simplest and when you free a sprite, update that index if the sprites index if lower than it, likewise when you create a sprite set that index to that one +1.

Given that sprites can hold custom properties it's simple enough to have an int that defines the kind of sprite that it is (in terms of your game) and call different functions for different behaviour logic.

It seems like this thread is sort of overthinking things: you could do "machine learning" by just writing the player's actions and the outcomes to a file, then have your AI logic read that file, and use branching "if" statements. Overall, the AI logic would be like, "the player tends to go left more than right, so err that way", or "half the time the player went up the middle they scored, so defend there."

You could technically use this approach on much weaker hardware than the Switch. I've even thought of making "adaptive" AI in an Atari ST game or something, I think it'd work fine.

@HeavyByte That is true, though for now we have to make do with what we can come up with so far. But I'm sure the Fuze team have these issues in mind and will make improvements in later patches.

@PB____ yeah, that's what I was trying to avoid. I'd rather just type the extra "\n" and save the extra syntax and compute cycles. Thank you though!

Check out LinkCraft’s pong game, it might help. https://fuzearena.com/forum/post/5593

Here’s the thread talking about it https://fuzearena.com/forum/topic/657/split-screen

I found it using the forum search ;P

Yeah a long time ago i think it could work this way but it was wrong

@toxibunny in strictly typed languages (e.g. like java, kotlin, c++, etc.) enums are great to achieve the domain definition. E.g. you know that the value passed to certain method can only be one of {EMPLOYEE, CONTRACTOR, ...} but nothing else. Enum make sure that whtever is passed int he method has this contraint at 1) compile time where possible 2) in case the data is fetched from external source and e.g. deserialized into enum the runtime error is thrown if they won't fit inside the domain defined. Well apprarently in dynamic typed language this doesnt' make too much of sense from a laguage protection level and it's used just to make the code more clean (as suggested with the struct above)

@Willpowered I figured it was either that or conditional jumps take a lot of time 🤔

This forms the basis for more or less everything I write - maybe useful?

float scale = 3.5 float tile_size = 8 * scale game = [ .active = false, .rows = 24, .cols = 32 // ... game stuff too... ] spectrum_buffer = createImage( game.cols * 8, game.rows * 8, false, IMAGE_RGBA ) offset_x = ( gWidth() - ( tile_size * game.cols ) ) / 2 offset_y = ( gHeight() - ( tile_size * game.rows ) ) / 2 loop if !game.active then show_splash() endIf initialise_variables() while game.active loop game_loop() repeat // If lives aren't zero then the game was quit prematurely. if game.player.lives == 0 then game_over() endIf repeat /** * Displays the intro/ "Pre-Game" screen. */ function show_splash() while !game.active loop setDrawTarget( spectrum_buffer ) clear() // This prints in "Spectrum font" obviously normal printing will be huge here. // My Spectrum font is 8x8 pixels as per the Spectrum (the "7, 3" is specific for West Bank - the font is double height and has an attribute value for top/ bottom). spectrum_print( 11, 0, "WEST BANK", 7, 3 ) // etc c = controls( 0 ) if old_c and !(c.a or c.b or c.x or c.y) then game.active = true endIf old_c = c.a or c.b or c.x or c.y setDrawTarget( framebuffer ) clear() drawImage( spectrum_buffer, offset_x, offset_y, scale ) update() repeat return void

I've simplified it somewhat for here, but I think that demos enough what I mean.