Calculator Community > Axe

Converting from Prgm to App

<< < (3/4) > >>

Ki1o:
I am making a state machine for the game, and yeah... I was trying to be... efficient? I was trying to find a way to avoid repeating the same code and I wanted to see if there was a different way instead of using If for each key. I don't know why I also didn't think of simply using If...ElseIf instead. I guess I was fixated on making this specific solution work.
The main game loop itself is pretty simple:

--- Code: ---Lbl Main
Init()
Game()
Return
Goto MAINEND
Lbl Init
0→Frame→Quit→ScrollXOffset→ScrollYOffset→PlayerX→PlayerY+6*8→MapX→MapY
°TileMap→Map
DrawMap()
ʟUpdateGame→UpdateState
ʟDrawGame→DrawState
Return
Lbl Update
Frame++
(UpdateState)()
Return
Lbl Draw
(DrawState)()
Return
Lbl Game
While 1
Update()
Draw()
EndIf Quit
Return
--- End code ---
The idea is that Update and Draw are called every frame which then calls their respective "State" function for that frame. This is opposed to the logic in my code on GitHub where technically, I was doing all of the scrolling within the span of a single game frame. This way, every update and draw call game happens on a per frame basis.
Since I was just working on the movement I haven't added any collision checks yet but I will. I'm also all for code critiques. Honestly, some of my code is a little... weird because I'm also a student so every new CS concept I learn I try to see how it would be done in Axe, resulting in a lot of... pasta

E37:
@Ki1o
State machines are efficient and there is nothing technically wrong with your implementation. They just get complex very quickly and unless very small or very carefully documented are very difficult for your future self to come back and debug. If you can deal with that, there is no reason not to use them.
I wouldn't worry at all about optimization. Heavily optimized Axe code is very difficult to read and that is the last thing you need when you are still learning. Besides, heavy optimization is usually only worth at the most a 20% speedup unless the code is especially inefficient. You will usually get much more significant gains from reorganizing logic - which is easiest if you have clean code.

When I was learning how to program I messed around a lot like you. I have thrown away far more code than I have kept but learned a lot from it - hence the signature below my avatar! Also, re-implementing concepts in Axe is a really good way to understand them. If you can write it in Axe, you can do it any language.

If you are interested, I can send you the source for a real-time strategy game I programmed in Axe. Here is some screenshots. You will need an 84+ SE to hold all the source and the compiled code and I use several custom axioms. It will be quite difficult to follow the flow of execution (although individual features shouldn't be awful)

Ki1o:
@E37 Oh man that RTS game is very very nice. I'd love to check out the source. Is the game running at 6MHz? If so how did you squeeze out such performance while handling grayscale? If not, its still very impressive. I'm also curious about the font. Is that your text axiom? Either way I am definitely interested in learning more.

E37:
@Ki1o

The game runs at 15MHz but that is mostly because of graphics. Without drawing, the game could easily run at 3MHz. If I wrote everything in assembly, I could probably get it in its current state to run at 6MHz but it relies on other hardware features of the TI-84+ so it will never run on an 83. Compiled, it is over 100k of executable code. Does the 83 even have that much flash? I guess I could compile the game as an OS but that is way too much work.

The font is my text axiom. You can do the same thing with the built in Text command but that requires a font hook which requires some Asm work. Axe normally just calls TI-OS's text drawing command which is why mine is so much faster.

Ki1o:
@E37 I really need your help. I think I'm close to approaching my wit's end with Axe as a whole. This may seem sudden, but I am continuously running into issues that I simply cannot explain or find a cause for. At this point it is probably safe to assume that the language is bugged in some way or maybe I'm just bad with it. So I'm hoping that you can help me one last time. I was feeling really optimistic earlier, but it seems I can never make any progress on this project without problems. I'll try to explain what I'm experiencing. Right now, all I have is the simple game loop I posted earlier and the Update code along with the tile map code and a single draw function. I took your advice about the input code and optimized to something that worked and I liked. However, adding any more code to this project now seems to break it. It doesn't draw to the screen, it simply quits and says done. I'm going to attach the source so that maybe you can test it whenever you get a chance. The thing that broke the code is anything that I added dealing with changing direction. Which is very trivial and shouldn't break anything, but it does. So please, please help me make sense of this. What am I doing that is so wrong?

Navigation

[0] Message Index

[#] Next page

[*] Previous page