I need a basic screen framework like diddy2 but for AGK. I'm willing to pay to get this done for me. If anyone is capable, has the time and is willing can you email me or post here and we can discuss it, includin costs.
Thank you.
I'm not familiar with diddy 2 but if you can describe what you'd ideally like then if I already have something similar in my framework I'll send it over to you for free :)
Screen frameworks usually handle:
- update / render current "screen object"
- transition between "current object" and "last/next screen objects"
- have "prepare/firststart/init/afterXYZ/beforeXYZ" function/hooks which are called in the approbriate situations for screen objects to create objects, clean up, prepare stuff ...
So in essence you create screens for start menus, loading screens, publisher logo, ingame, gameover, ... and then just tell in your logic to go to the screen XYZ. If you are on your "start screen" a "previous screen" command would lead to exiting the app - except you re-wire connections manually.
bye
Ron
I'm thinking it might be this (https://github.com/therevills/diddy2)
Derron summed it up perfectly. Do you have anything like this, Qube?
Quote from: Derron on May 26, 2019, 22:06:31
Screen frameworks usually handle: ........
Thanks, I guessed as much in regards to what Diddy can do on this side.
Quote from: blinkok on May 26, 2019, 22:48:52
I'm thinking it might be this (https://github.com/therevills/diddy2)
Yeah, I've heard of Diddy but I've never used Monkey 2 and thus I'm not familiar with all that Diddy does to help with game creation.
Quote from: Amon. on May 26, 2019, 23:36:46
Derron summed it up perfectly. Do you have anything like this, Qube?
Oddly enough I don't have a framework for this as I code my games in a fashion where I can call any scene at any time anyway and fade in / out with a simple function call. I can see the benefit of having a more framework approach over a coding approach so it's something I'd be interested in doing along with my updated AGK framework stuff.
When I get around to doing this side and if I can make it separate enough from the rest of the framework then I'll happily provide the code for free. In the meantime if someone offers to code a system up for you then of course feel free to take their offer.
What you have now sounds pretty cool, Qube. I'd be interested in trying it. :)
Quote from: Amon. on May 27, 2019, 11:48:23
What you have now sounds pretty cool, Qube. I'd be interested in trying it. :)
This is probably not what you're after but is roughly what I do in my games to change between scenes and menus. Anyway, hope some part of it is of use.
Attached is a full project you can load straight into AGK and test ( use the latest version of AGK Classic )
Instructions of what this does as a scene change example.
1.. Fades in and out of each section
2.. Press SPACE to go from Main Menu to Main Game
3.. Press SPACE in Main Game to change level
4.. Press M in Main Game to change to a Mini Game
5.. Press SPACE in a Mini Game to return to the Main Game
6.. Press ESC in the Main Game or Mini Game to return to the Main Menu
7.. Press ESC on the Main Menu to QUIT
Source ( included in the attachment ) :
Global screenWidth As Float = 1024
Global screenHeight As Float = 576
SetWindowTitle( "Scene Test" )
SetWindowSize( screenWidth, screenHeight, 0 )
SetWindowPosition( ( GetMaxDeviceWidth() - GetWindowWidth() ) / 2, ( ( GetMaxDeviceHeight() - GetWindowHeight() ) / 2 ) )
SetWindowAllowResize( 0 )
SetVirtualResolution( screenWidth, screenHeight )
SetDisplayAspect( screenWidth / screenHeight )
SetOrientationAllowed( 0, 0, 1, 1 )
EnableClearColor( 1 )
SetRandomSeed( GetUnixTime() )
SetRandomSeed2( GetUnixTime() )
SetRawMouseVisible( 0 )
SetVsync( 1 )
SetClearColor( 0, 0, 0 )
UseNewDefaultFonts( 1 )
Global targetFrameRate As Float = 60.0
Global gameAtlas As Integer, deltaTime As Float, gameScene As String, gameWorld As Integer, gameLevel As Integer, nextScene As String
Global fadeMode As Integer, fadeValue As Float, fadeStage As Integer, fadeAction As String
Global spritePixel, spriteBall, spriteMenu, spriteGame, spriteMini
Global ballAngle As Float
Dim numbers[ 9 ]
Variables()
PrepareMedia()
gameScene = "Main Menu"
fadeMode = 0 // start with fading in
//
// MAIN LOOP
//
Do
// SCENES
If gameScene = "Main Menu" Then MainMenu()
If gameScene = "Game" Then MainGame()
If gameScene = "Mini Game" Then MiniGame()
// CHANGING OF SCENES
If fademode = -1
If GetRawKeyPressed( KEY_SPACE )
If gameScene = "Main Menu"
gameLevel = 1
ChangeScene( "Game", "" )
EndIf
If gameScene = "Game"
ChangeScene( "Game", "Next Level" )
EndIf
If gameScene = "Mini Game" Then ChangeScene( "Game", "" )
EndIf
If GetRawKeyPressed( KEY_M )
If gameScene = "Game" Then ChangeScene( "Mini Game", "" )
EndIf
If GetRawKeyPressed( KEY_ESCAPE ) And gameScene <> "Main Menu" Then ChangeScene( "Main Menu", "" )
If GetRawKeyPressed( KEY_ESCAPE ) And gameScene = "Main Menu" Then END
EndIf
// FADING AND ACTIOND AFTERWARDS
If fadeMode = 0 Then FadeIn( fadeAction )
If fadeMode = 1 Then FadeOut( fadeAction )
// SWAP AND REPEAT
Swap()
GetDeltaTime()
Loop
//
// MAIN MENU
//
Function MainMenu()
Sprite( spriteMenu, screenWidth / 2 ,screenHeight / 2, 255, 255, 255, 255, 1 )
EndFunction
//
// GAME
//
Function MainGame()
For i = 0 To 359 Step 20
Sprite( spriteBall, ( screenWidth / 2 ) + Cos( i + ballAngle ) * screenHeight / 2.2, ( screenHeight / 2 ) + Sin( i - ballAngle * 2 ) * screenHeight / 2.2, 255, 255, 255, 255, 1 )
Next
Inc ballAngle, 1 * deltaTime
If ballAngle >= 360 Then Dec ballAngle, 360
Sprite( spriteGame, screenWidth / 2 ,screenHeight / 2, 255, 255, 255, 255, 1 )
Sprite( numbers[ gameLevel ], screenWidth / 2, ( screenHeight / 2 ) + 50, 255, 255, 255, 255, 1 )
EndFunction
//
// MINI GAME
//
Function MiniGame()
For i = 0 To 359 Step 30
Sprite( spriteBall, ( screenWidth / 2 ) + Cos( i + ballAngle ) * screenHeight / 2.2, ( screenHeight / 2 ) + Sin( i + ballAngle ) * screenHeight / 2.2, 255, 155, 155, 255, 1 )
Next
Inc ballAngle, 1 * deltaTime
If ballAngle >= 360 Then Dec ballAngle, 360
Sprite( spriteMini, screenWidth / 2 ,screenHeight / 2, 255, 255, 255, 255, 1 )
EndFunction
//
// SETUP TO CHANGE SCENE
//
Function ChangeScene( fScene As String, fAction As String )
nextScene = fScene
fadeAction = fAction
fadeMode = 1
EndFunction
//
// FADE IN
//
Function FadeIn( fAction As String )
// init the fade
If fadeStage = 0
fadeStage = 1
fadeValue = 255
EndIf
// do the fade
Dec fadeValue, 3 * deltaTime
If fadeValue <= 0
fadeValue = 0
fadeStage = 0
fadeMode = -1
// any actions to take after fading?
EndIf
// draw super zoomed sprite
Sprite( spritePixel, 0, 0, 0, 0, 0, fadeValue, 0 )
EndFunction
//
// FADE OUT
//
Function FadeOut( fAction As String )
// init the fade
If fadeStage = 0
fadeStage = 1
fadeValue = 0
EndIf
// do the fade
Inc fadeValue, 5 * deltaTime
If fadeValue >= 255
fadeValue = 255
fadeStage = 0
fadeMode = 0
If nextScene > "" Then gameScene = nextScene
nextScene = ""
// any actions to take after fading?
If fAction = "Next Level"
Inc gameLevel
If gameLevel > 9 Then gameLevel = 1
EndIf
EndIf
// draw super zoomed sprite
Sprite( spritePixel, 0, 0, 0, 0, 0, fadeValue, 0 )
EndFunction
//
// PREPARE MEDIA
//
Function PrepareMedia()
gameAtlas = LoadImage( "media.png" )
temp = LoadSubImage( gameAtlas, "whitepixel.png" )
spritePixel = CreateSprite( temp )
SetSpriteSize( spritePixel, screenWidth, screenHeight )
temp = LoadSubImage( gameAtlas, "ball.png" )
spriteBall = CreateSprite( temp )
temp = LoadSubImage( gameAtlas, "mainmenu.png" )
spriteMenu = CreateSprite( temp )
temp = LoadSubImage( gameAtlas, "gamelevel.png" )
spriteGame = CreateSprite( temp )
temp = LoadSubImage( gameAtlas, "minigame.png" )
spriteMini = CreateSprite( temp )
For i = 0 To 9
temp = LoadSubImage( gameAtlas, Str( i ) + ".png" )
numbers[ i ] = CreateSprite( temp )
Next
EndFunction
//
// SPRITE FUNCTION
//
Function Sprite( fImage, fXPos As Float, fYPos As Float, fRed, fGreen, fBlue, fAlpha, fHandle )
If GetSpriteExists( fImage ) = 0 Then ExitFunction
SetSpriteColor( fImage, fRed, fGreen, fBlue, fAlpha )
If fHandle = 0 Then SetSpritePosition( fImage, fXPos, fYPos ) // top left handle
If fHandle = 1 Then SetSpritePosition( fImage, fXPos - ( GetSpriteWidth( fImage ) / 2.0 ),fYPos - GetSpriteHeight( fImage ) / 2.0 ) // center handle
DrawSprite( fImage )
EndFunction
//
// DELTA TIME - super cheap method
//
Function GetDeltaTime()
deltaTime = GetFrameTime() * targetFrameRate
EndFunction
//
// SETUP VARIABLES
//
Function Variables()
fadeMode = -1
fadeStage = 0
#constant KEY_BACK 8
#constant KEY_TAB 9
#constant KEY_ENTER 13
#constant KEY_SHIFT 16
#constant KEY_CONTROL 17
#constant KEY_ESCAPE 27
#constant KEY_SPACE 32
#constant KEY_PAGEUP 33
#constant KEY_PAGEDOWN 34
#constant KEY_END 35
#constant KEY_HOME 36
#constant KEY_LEFT 37
#constant KEY_UP 38
#constant KEY_RIGHT 39
#constant KEY_DOWN 40
#constant KEY_INSERT 45
#constant KEY_DELETE 46
#constant KEY_0 48
#constant KEY_1 49
#constant KEY_2 50
#constant KEY_3 51
#constant KEY_4 52
#constant KEY_5 53
#constant KEY_6 54
#constant KEY_7 55
#constant KEY_8 56
#constant KEY_9 57
#constant KEY_A 65
#constant KEY_B 66
#constant KEY_C 67
#constant KEY_D 68
#constant KEY_E 69
#constant KEY_F 70
#constant KEY_G 71
#constant KEY_H 72
#constant KEY_I 73
#constant KEY_J 74
#constant KEY_K 75
#constant KEY_L 76
#constant KEY_M 77
#constant KEY_N 78
#constant KEY_O 79
#constant KEY_P 80
#constant KEY_Q 81
#constant KEY_R 82
#constant KEY_S 83
#constant KEY_T 84
#constant KEY_U 85
#constant KEY_V 86
#constant KEY_W 87
#constant KEY_X 88
#constant KEY_Y 89
#constant KEY_Z 90
#constant KEY_F1 112
#constant KEY_F2 113
#constant KEY_F3 114
#constant KEY_F4 115
#constant KEY_F5 116
#constant KEY_F6 117
#constant KEY_F7 118
#constant KEY_F8 119
#constant KEY_S1 186
#constant KEY_S2 187
#constant KEY_S3 188
#constant KEY_S4 189
#constant KEY_S5 190
#constant KEY_S6 191
#constant KEY_S7 192
#constant KEY_S8 219
#constant KEY_S9 220
#constant KEY_S10 221
#constant KEY_S11 222
#constant KEY_S12 223
EndFunction
That's pretty much what I needed. Thank you, Qube. :)
Quote from: Amon. on May 28, 2019, 07:08:38
That's pretty much what I needed. Thank you, Qube. :)
Cool, so long as it's of some use or points you in the direction you want.
When I redo my framework it'll be a much neater system and I'll no longer need to code in things like the above or pausing a game / music & sounds etc. Just straight to coding the game ;D
Quote from: Qube on May 28, 2019, 18:41:53
Quote from: Amon. on May 28, 2019, 07:08:38
That's pretty much what I needed. Thank you, Qube. :)
Cool, so long as it's of some use or points you in the direction you want.
When I redo my framework it'll be a much neater system and I'll no longer need to code in things like the above or pausing a game / music & sounds etc. Just straight to coding the game ;D
Now that would be cool. What you have sorted for us so far is still good so thanks for that and I look forward to the next framework. :)
Quote from: Amon. on May 28, 2019, 19:10:12
Now that would be cool. What you have sorted for us so far is still good so thanks for that and I look forward to the next framework. :)
Ah, that'll be for internal use and not a freebie, sorry :( :P
Quote from: Qube on May 28, 2019, 19:56:00
Quote from: Amon. on May 28, 2019, 19:10:12
Now that would be cool. What you have sorted for us so far is still good so thanks for that and I look forward to the next framework. :)
Ah, that'll be for internal use and not a freebie, sorry :( :P
HOW DARE YOU DENY ME DA CODEZ! :)
One quick question: What is the best way to display text using the Print function when using Swap() instead of Sync()?
QuoteHOW DARE YOU DENY ME DA CODEZ! :)
Sure, OK, I'll just slave away and provide everything you need :))
QuoteOne quick question: What is the best way to display text using the Print function when using Swap() instead of Sync()?
Never used the Print command and I can't see how to render it without Sync() :o
However you could use the other built in commands for text ( more flexible ). You could also wrap up a Function to work like Print.
If I'm ever using the built in text commands then I cheat a little by reassigning the text of a Global variable or else you're supplying one variable per line of text and I think that's just silly.
Like so :
Global myText As Integer
CreateText( myText, "" )
SetTextSize( myText, 50 )
Do
SetTextString( myText, "Hello" )
SetTextPosition( myText, 100, 100 )
DrawText( myText )
SetTextString( myText, "World!" )
SetTextPosition( myText, 140, 140 )
DrawText( myText )
Swap()
Loop
Quote from: Qube on May 28, 2019, 19:56:00
Quote from: Amon. on May 28, 2019, 19:10:12
Now that would be cool. What you have sorted for us so far is still good so thanks for that and I look forward to the next framework. :)
Ah, that'll be for internal use and not a freebie, sorry :( :P
Sell it.
Quote from: LineOf7s on May 29, 2019, 00:15:13
Sell it.
I'd have to do full documentation, multiple examples of how to use and spend a lot of time offering support ( based on if it'd even sell ). My real life work unfortunately wouldn't allow the time I'd prefer to support such a thing and I'd never release something commercial that I couldn't support properly.
I think the market for a full AGK game framework is very small to be honest.
You're not wrong there.
Still, for that small market - and the right price - maybe selling it "as-is" (eg comments = documentation) is enough? Support's always a pain though. I can see why people might be inclined to just release code into the wild (open source and/or public domain) just so they can say "No support! Leave me alone!" and get on with their lives. :)
Open Source does not mean you do not have to do some kind of support / are liable - which is why many licences limit liability ;-)
You cannot invent a mass destruction weapon, put up the sources and say "it is up to you what you do with it" ...albeit none of our codes is a MDW 8)
@ economic environment of AGK
Yes I think it is a small world in which you would sell your framework. Benefit is the lack of "competitors" and that people (most of them at least ;-)) already have shown their will to pay for stuff (they bought AGK).
bye
Ron
Anything that is endorsed by TGC might have some commercial success. If you are on your own, you will find yourself getting unnoticed quickly. Imho it isn't worth the effort.
Quote from: Derron on May 29, 2019, 07:03:38
@ economic environment of AGK
Yes I think it is a small world in which you would sell your framework.
I agree. Even if I were to make a super excellent framework I think I'd be lucky to even reach 50 sales to be honest. The thought of selling it ( when it's all done along with the tools ) never entered my head. Yup, it'll remain for my own personal use, it'll be too awesome to sell ;D
@Qube:
Love your fading routine, very cool. 8)
Quote from: Rick Nasher on May 30, 2019, 18:54:50
@Qube:
Love your fading routine, very cool. 8)
Thanks. Very simple but handy for scene changes with "things to do" if needed.
Quote from: Rick Nasher on May 30, 2019, 18:54:50
@Qube:
Love your fading routine, very cool. 8)
Why? He is increasing a value or decreasing it - and executing/changing someting when it reaches a certain point.
Think this is what a fader does...
In a more OOP manner you would have a fader object which you update/render and which sends out events or runs callbacks which you can register. So you can run:
- onFadeStart
- onFadeProgress
- onFadeHalf
- onFadeEnd
...
That way you can easily start initializing stuff in your new scene or pause action or whatever you need to do.
Also this leads to:
- replaceable code (you can use other fader/effects by replacing one line in your code then)
- reusable code (not mixing game logic with presentation logic)
While Qube's code is (for now) simple enough to replace stuff here and there (eg with a function callback instead of straight game logic in the fader functions) I am sure that he would do it differently when it has to be added to his framework lib/code.
bye
Ron
QuoteWhy? He is increasing a value or decreasing it - and executing/changing someting when it reaches a certain point.
Perhaps he just liked the simple method of using a single pixel and being able to do other things?. Doesn't have to be over complex to be liked.
QuoteIn a more OOP manner
OOP for everything!
The Faster You Unlearn OOP, The Better For You And Your Software (https://www.gamedev.net/articles/programming/general-and-gameplay-programming/the-faster-you-unlearn-oop-the-better-for-you-and-your-software-r5026/) ;D
QuoteWhile Qube's code is (for now) simple enough to replace stuff here and there (eg with a function callback instead of straight game logic in the fader functions) I am sure that he would do it differently when it has to be added to his framework lib/code.
True, this is just a version of what I use at the moment as it's super simple to use. When part of my shiny new framework it won't be in this manner as I want to also have different effects and options available during the fade process.
Quote
Why? He is increasing a value or decreasing it - and executing/changing someting when it reaches a certain point.
It's called not over-complicating something that does not need to be over-complicated!
Quote
In a more OOP manner you would have a fader object which you update/render and which sends out events or runs callbacks which you can register. So you can run:
- onFadeStart
- onFadeProgress
- onFadeHalf
- onFadeEnd
...
Oh please! Events and callbacks for such a simple task. :P
When all you have is a hammer, everything looks like a nail.
In other words when all you have is an OOP approach, every little piece looks like an OOP solution. Which is nonsense, can overcomplicate and make your code inflexible to changes.
Callbacks/Events are the way to go if you give your code to third party programmers / writing libraries.
As soon as your code becomes kind of a "black box" you will have to allow modification somehow.
OOP makes it flexible to change - as all you need is to use another "variant" (eg "extending class").
If you wanted to reuse your code but this time you want to have some mosaique-transition instead of a fade-to-black you need to code it in both fashions yes - but then, after some time you see that the base logic has a flaw or needs extension. Now you have to go through all your different "fader functions" and update/fix the portion. Then you go to another project you were using this code too - again copy/paste functions around and maybe pasting stuff over functions which had little adjustments here and there (slower fade, other color, ...).
In OOP (or if you split your fading stuff into multiple functions - its the same then you replace your "fader.base.file" with the new file, recompile the application and you are done.
Of course you do not have to write a complete fader class if you intent to only use it ONCE in all your projects. KISS then.
But if your plan is to create stuff to reuse in other projects - or stuff which needs to be configurable ("modding") or dynamic ("scripted") then you won't be able to keep it that simple.
You plan to have multiple faders simulataneously (eg. a split-screen game)? Have two fader objects/instances instead of copying functions to not interference with some globals you are using - or maybe having to add some functions just to make the "second split screen world" still updating and rendering.
OOP (or other stuff) are in no way the holy grail but there is a reason for such stuff to be still thought and used in many projects. Rapid prototyping is of course something different and also I did not want to say Qube's code is bad. It's just that the whole approach is not something "wow" or "magnificient". It is something I would consider "basic knowledge" (inc or dec values and use the value to do something) for non-beginners in coding. It's like the usage of "sin" to smoothly do transitions between two values (there are other formulas/functions ... I know).
bye
Ron
QuoteI did not want to say Qube's code is bad. It's just that the whole approach is not something "wow" or "magnificient". It is something I would consider "basic knowledge" (inc or dec values and use the value to do something) for non-beginners in coding.
The code was not meant as a showcase how how great I am ;D - It was a simple solution to Amon asking how you could code game transitions with fade in / out in AGK.
@ Qube
I know that it was just to show how things could be done and I am not saying it is bad - I just defended why I questioned Ricks "Love your fading routine, very cool. 8)" - especially as it is nothing "special" - maybe things are different if you never had any fade in your games and think of using a "progress indicator" (= your fade value multiplier) as something they'd never come up.
bye
Ron
You know what?
Fading a screen is something 'Very special'! it's not the simple task it first looks, especially when there are other controls or displayed object to take care of.
You need to have 'thought' about all the other stuff and how they fit together and operate.
I'm with Rick - very cool fading routines. It's very special :)
Derron it's very rude and quite arrogant to say somebody else's code is not very impressive in your eyes, when others have praised it. You might want to think and keep some thoughts to yourself.
And as for OOP there are plenty of ways to code software, every time you keep jumping on threads telling people how to code their own damn projects! If advice is ASKED for then fair enough. If somebody is very happy how their code runs (efficient, fast and easy to follow) then you come along, oh that's not very good I would have done it THIS way. Then we come back to arrogance and just plain being rude.
I wanted to know why he praised it as I do not see it doing stuff we others would not do too.
Also I wrote that I do not want to offend Qube but wanted to know why the code was found as being "loveable". I also explained why I would use some kind of "hooking/callback" system (OOP based or not).
Repeat: I do not want to sound arrogant. But please remember that Rick is no beginner in programming - he wrote some cool looking stuff in the past which is why I questioned the piece of code being "loveable". Maybe I just am not able to see what it does differently to how we others would tackle it. So please explain what this code does what you did not think of before .. what makes it "very special"?
@ Adam
Of course fading a screen can be "very special" - but the routine posted here is ... update a value, handle stuff and render your fading effect according to the value. It's how we all would handle it - just not in the way _I_ would do it. Maybe AGK even does not allow that, dunno, am not using AGK.
I understand what you mean with controls - controls need to be "scaleable", multiple alpha effects need to take a "global alpha" into consideration (best is to have all rendered on a single texture - which your global fading thing then fades/scales/rotates/... for you).
I think above's stuff is best handled in a OOP/hook/callback system - and everything of course under the assumption of being "library" code not just something you have in your prototype app.
bye
Ron
Quotebut the routine posted here is ... update a value, handle stuff and render your fading effect according to the value
Not to drag this pointless debate on but it's not strictly that. It's a simple method to fade out your screen, change level ( scene ), take any actions after fade out and then fade in the screen with just calling one command.
While simple to you and no doubt many others it may be helpful to someone who's never done this before and as it's simple code perhaps that why *some* just like it as it doesn't involve anything complex or OOP gymnastic with hooks and callbacks and before, mid, during fluffy bits.
Just a simple approach to use one command to fade out, change scene and fade in the next scene.
Maybe it needs to be done that way as AGK limits the user with its language/syntax?
Of course a screen fader does what you describe - in this or another style/approach. I just thought it is a bit tedious if you needed a multitude of little variations - copy pasting functionality and hoping that the basics never change (as it meant a dozen of manual replacements then).
I understand that for _some_ this code looks interesting but as said I took Rick Nasher's "knowledge" (comments, posts, projects) into account too - which made me wonder as I assume he would be able to do that too - except (see first sentence) it was a bit of tricky to achieve with AGK (dunno about limitations there).
Nonetheless: you made it available for free - and this is always cool beans!
bye
Ron
QuoteMaybe it needs to be done that way as AGK limits the user with its language/syntax?
Exactly, you do not know AGK and it's has no OOP so saying it SHOULD be done via OOP in an AGK based thread is mute.
I can't stress enough that the code was just some tiny example I whipped up on how I currently code this in my games to do something that Amon was interested in.
As also stated I don't have a proper game framework yet, hence "this is just the method I use". It's not clever code, smart code or impressive code. Its just a simple example of doing something. Perhaps Rick just liked the overall simplicity of being able to fade out / in / change game scenes with just one command, I don't know.
I'm sure Rick will explain to you why he happened to like it if it's bothering you that much.
Yes it is bothering me - as the code itself is not doing some black magic stuff but pure "logic" and I want to know whether he liked it as he learned something new out of it or did not know of a way on how to achieve that with AGK (which might be an issue of the language).
Also I do not say you need to do it "OOP" - I said you could use callbacks or other options to have a dynamic behaviour. Something which allows to reuse your code or even to use it multiple times simultaneously. I assume in AGK it would need some arrays or so but still the code would be more flexible then. Same for callbacks or other "hook your functionality into existing code without requiring altering this code".
So maybe you can tell me (so I can learn something) if such "dynamic connections" are not possible with AGK that easily. Think it is needed for a proper (and flexible) framework and as you are writing one for you I assume there are ways to achieve that.
bye
Ron
Wow.
In a programming forum: someone asked a question, someone else provided an example of how he could do it, and someone else again expressed appreciation for the method.
If any part of that is "bothering" anybody, perhaps this forum is a little too uncomfortable for you.
QuoteSo maybe you can tell me (so I can learn something) if such "dynamic connections" are not possible with AGK that easily.
OK, very quick crash course in AGK's language structure.
1.. No OOP.
2.. The closest thing to OOP is Types to which you can use to store data like : bullet.xpos bullet.ypos bullet.speed etc etc.
3.. It's procedural programming ( functions )
4.. You can return a variable from a function. For example :
If AddThis( 2, 2 ) = 5 Then END
Function AddThis( var1 As Integer, var2 As Integer )
Local answer As Integer
answer = var1 + var2
EndFunction answer
5.. You can have Types in Types ( + insert, delete, sort types )
6.. You can pass Types via reference
And that's pretty much it in regards to any fancy language features. The rest is down to the built in commands and your coding imagination :)
So you cannot pass a function reference to another function to call it there then?
Or store function references at least in an array or so...so you pass an integer to somehow reference / identify a dynamically positioned entry of that function array?
Would be pretty limiting in my opinion (way less flexible). Only reason I see for this would be optimization as all potential paths are known on compilation not execution.
Thanks for the crash course.
Bye
Ron
You can call a function from another function but you can't have a function in a function. You can pass and return variables to / from a function.
I am talking about something like this:
Function CallFunction:int(func:int())
if func then func()
End Function
Function MyFunction:int()
print "hi"
End Function
CallFunction(MyFunction)
So in essence something which allows callbacks.
For now I think you can only have stuff like "DrawButton(index)" with "index" pointing to various arrays for "x, y, w, h, label, clickState" ... but if you eg. intend to have a button get drawn differently (icon added or so) you have to prepare it in your "DrawButton()" function already (with another "icon array/dim" even if only 2 of 100 buttons require an icon). Your code / loop would need to always check button states of all buttons to see they are clicked - or your "UpdateButton()" would need to get tinted with game logic ("If MouseClicked ... if buttonStates[10] = 1 Then FadeToMainMenu()").
This is btw something I found notionworthy in your code (the mix of fade - and gamelogic). But it seems that this is a limitation in the AGK language enforcing such a coding style.
So now I am even more interested in how you tackle it in your new framework code (no real code needed, just want to know how you make it "flexible" - if possible).
I can imagine that for rapid prototyping this might be maintainable but I wonder how to do a proper (customizable) framework then. Might lead to a lot of hoops to jump?
bye
Ron
Quote from: Derron on June 01, 2019, 10:44:14
I am talking about something like this:
You can do that with tier 2 AGK, but not tier 1. Tier 1 is a BASIC syntax with some added functionality, more akin to Blitz3D or BlitzBasic.
QuoteFor now I think you can only have stuff like "DrawButton(index)" with "index" pointing to various arrays for "x, y, w, h, label, clickState"
AGK has its own virtual button routines, but if you want to create your own: You would only need 1 array of type "Button" which would hold all the info you need.
Quotebut if you eg. intend to have a button get drawn differently (icon added or so) you have to prepare it in your "DrawButton()" function already (with another "icon array/dim" even if only 2 of 100 buttons require an icon).
Unless you want flat 2d butons, they probably all need some sort of image already. Otherwise, your statement is true, any extra information would need to be stored whether you need it or not. No
class ButtonWithImage extends Button possible.
QuoteYour code / loop would need to always check button states of all buttons to see they are clicked - or your "UpdateButton()" would need to get tinted with game logic ("If MouseClicked ... if buttonStates[10] = 1 Then FadeToMainMenu()").
This is how procedural languages work. You control when io gets polled, Why have the game pause during AI or physics calculations just to change the state of a button or respond to a keypress?
QuoteThis is btw something I found notionworthy in your code (the mix of fade - and gamelogic). But it seems that this is a limitation in the AGK language enforcing such a coding style.
Not a limitation, just a preference. Personally, I prefer a more OOP approach, but some prefer a more procedural approach. One reason I liked Blitzmax as it seemed a good balance between the two.
QuoteThis is how procedural languages work. You control when io gets polled, Why have the game pause during AI or physics calculations just to change the state of a button or respond to a keypress?
Maybe this is why I buried it so far far far in the darkest corners of my brains ;-)
Dunno if I got your last sentence correct but callbacks/events do not do something differently than a function you call in your loop - just with the possibility to change this function more flexible. They all "block" as they do something (even if it is just setting a variable for a thread).
Thanks for your elaboration about (Tier 1) AGK. Wonder why they kept it that way instead of extending the language here and there (...as long as nobody is forced to use it people should be happy). As said BlitzMax offers a kind of "mix" between both things (as for many modules a procedural interface is provided).
Regarding "Not a limitation, just a preference." I think it is a kind of limitation except it was possible to do differently. Same for a languages having other limits (Lua's interpreter is having an odd time with break/return - especially prior 5.2). It's not a preference but a limitation (intented or not).
Still eager to read how Qube plans to tackle / tackles flexibility aspects in his GUI framework or scene management functionality.
Quote from: Derron on June 01, 2019, 10:44:14
I am talking about something like this:
Function CallFunction:int(func:int())
if func then func()
End Function
Function MyFunction:int()
print "hi"
End Function
CallFunction(MyFunction)
No, you can't do that, you'd have to do something like silly like :
Function CallFunction( func As String )
if func = "MyFunction1" then MyFunction1()
End Function
Function MyFunction1:int()
print "hi"
End Function
Function MyFunction2:int()
print "me"
End Function
CallFunction( "MyFunction1" )
Quote from: Derron on June 01, 2019, 10:44:14
So now I am even more interested in how you tackle it in your new framework code (no real code needed, just want to know how you make it "flexible" - if possible).
I sort of cheat a lot using Types and of course well thought out clean coding. For example in my GUI ( which is almost complete including designer \o/ ) you can do something like this to get / change things :
// say I have 10 windows open which are all the same and each one has a slider to change the red colour of a text label - here's the code which works automatically for every window but only on the window in focus.
If guiEvent.label = "colour slider red"
guiFindGaget( guiEvent.window, "my boring label" )
guiGadgets[ guiFoundGadget ].red = guiGadgets[ guiEvent.id ].value
EndIf
Simple example of course but shows I'm not having to do mad coding when it comes to actually using the GUI. The whole GUI and event system is based on Types so no hard limit based on DIM's. I can also change gadgets in other windows which are not in focus or not even shown using the same code base as above.
Also the GUI designer spits out the source code for all windows and gadgets including all the possible events in that window so all I need to manually code is the actions for each gadget.
Overall the GUI has been coded to offer enough flexibility for most circumstances.
* updated *
Soon I'll be moving on to a fresh new approach to my framework which currently is causing way too much repeated code with every game I do. Again it will be designed around Types so I can set the scene with things like :
scene.fadeOut
scene.pause
scene.muteAudio
scene.slowTime
scene.saveData
All the commands for drawing and doing other stuff are designed around the scene framework so we will then be able to do something like :
If scene.keyPressed = "SPACE" Then scene.pause = 1
If scene.isGameOver Then scene.fade = 1
This would then trigger the framework to pause all sprite movement and pause any audio. Pressing space again then does the reverse.
You won't code your game using the built in commands but instead be using the frameworks version.
Sounds kind of clever regarding "sailing around" these obstacles hidden in the shallow AGK waters :)
guiFindGaget( guiEvent.window, "my boring label" )
guiGadgets[ guiFoundGadget ].red = guiGadgets[ guiEvent.id ].value
So your guiFindGadget() is populating "guiFoundGadget" with an ID (or instance reference) of the found widget?
If that happens: what happens if you call a function for a "widget" which does a "guiFindGadget()" too (eg in a dragndrop-interaction). Your functions would need to be aware of that culprit and backup "guiFoundGadget" into another variable, do their lookup + interaction and then finally restore the backup again into "guiFoundGadget".
Or do you handle it differently? Above is - as said - an assumption of something like a global variable which you use over and over and it works until some other code line is modifying it too.
@ scene management
Yes such stuff eases pain a lot.
GetCurrentScreen().FadeToScreen( GetScreen("mainmenu"), 0.2)
-> fade the current screen to the screen stored at "mainmenu". Fade duration is 200ms
There is a lot of convenience you can put into your framework functions. Eg. the screen gets informed about the pause/fadeout and would either stop game logic or pause it or ...
@ game project + framework
Think a lot of stuff would benefit from such managers: sound (music manager + sfx playlists for randomized usage of "boom" sounds and so on). bitmap font classes (styled block text, text animations, ...).
Cannot imagine what a hell that must be without "oop" (or similar approaches).
Again: all this is under the topic "framework" so something we plan to reuse over and over - compared to specific "only game x" logic.
Can't you use Tier2 to provide yourself some basic functionality which you then use in your Tier1 code? Kind of a "DLL" ?
bye
Ron
QuoteSo your guiFindGadget() is populating "guiFoundGadget" with an ID (or instance reference) of the found widget?
Yes, that's pretty much it.
QuoteIf that happens: what happens if you call a function for a "widget" which does a "guiFindGadget()" too (eg in a dragndrop-interaction). Your functions would need to be aware of that culprit and backup "guiFoundGadget" into another variable, do their lookup + interaction and then finally restore the backup again into "guiFoundGadget".
I don't do it that way as any gadgets which interact with other gadgets have their own dedicated code to avoid conflicts.
For example a listbox is made up of a vertical slider and a multiline textbox these two separate widgets are joined together by a guiGadgets[ ].childOf - When I move the slider, it knows there is a child gadget and the code to handle the multiline textbox gets fired.
In regards to drag and drop each relevant widget has a guiGadgets[ ].dragFrom, guiGadgets[ ].dragTo and guiGadgets[ ].dragInfo which again is all handled via dedicated code for that action. If I still need to find a gadget then there is a guiFindGadgetPrivate function ( this is only used by the GUI itself and not the user ) which goes into a queuing system and won't take any actions from the queue list until the guiFoundPrivate is -1 ( 0 means nothing found and then returns to -1 )
There's quite a lot of work around systems that result in the user end being neat enough and flexible enough to use, hence the auto code generation from the designer which saves even more typing and mistakes. I had to spend a lot of time building up the GUI core as I didn't want any limits on windows, gadgets, events etc.
There's an Early Video (https://www.syntaxbomb.com/index.php/topic,5448.msg26316.html#msg26316) showing 15 windows with timers being fired and still interacting with different GUI windows. Although the example syntax in the post has been streamlined since then too.
Quote@ scene management
Yes such stuff eases pain a lot.
That's the plan :) - I have a set of helper function when writing games which save time but every game I've done I'm always writing a lot of stuff over and over again but just in a different way. I thought it was about time I coded up some proper game based tools ( hence the gui and gui designer ) and code a proper framework system so all tasks like scenes, game gui's, fading, pausing / resuming action and music etc etc are all coded in an optimised manner as possible.
I have great plans for the map maker / level designer buts that's for another thread ;D
Think I understood a bit more about your approach (and the reasons for it). Thanks for your elaborative answers guys.
Seems AGK is not really my cup of tea - albeit its capabilities ("2d/3d" and "targets") are something I would like to see in BMX NG.
bye
Ron