I plan on making a scorched earth clone that uses user solved physics equations to determine how the game is played.

  • Features:
    -3 Game modes
    -Multiple weapons
    -Terrain and movement
    -Accurate game physics. nothing is "botched"
    -Dcs Gui Api for a professional look and easy to understand.
    -External question packs for easy question updating and additions
  • Game modes:
    -Standard - No Physics needed!.
    -Smarties Win -Available Actions are based on how well you answer -questions
    -Am I Close? - Show power and angle deviation are based on answer correctness.
I think the game modes for this sound particularly appealing, and I definitely hope you follow through. I'll do my best to remind you and all of the other contestants regularly so you pace yourself well; 8 weeks isn't as long as you think it is. I of course also like the idea of you using the Doors CS GUI, for obvious reasons. This is going to be TI-BASIC, or z80 ASM?
Z80 asm. Cant be struggled enough to mess with Ti-basic. The math can be scripted rather thoroughly...I can thank iambian for knowing how to make fast scripting engines.... Which will make everything pretty easy to do. I might scratch the accurate game physics from it and use calc physics for the trajectories and stuff as I'm not basing the actual game play on the physics only the question part of it. Have to see honestly know nothing about physics learning as I go here.

Also is there any better examples of the dcs gui other then the example on the wiki which really doesn't explain much?


Also by using the dcs GUI I can do multiple choice questions and such alot easier. as I don't have to do anything other then parse for a marked byte Razz
About Doors CS GUI examples, there are a few resources you can look at, most of which are bits of existing code. Actually, since you have access to the Doors CS source code, you can look at the best resource of all: the ways that the GUI API is used within Doors CS itself (which is how external programs use it to). You are also welcome to ask any DCS GUI-related questions, as that is not closely-enough linked to the contest topic to be out of bounds.
Where in the dcs code is that? cause i can just mess with that to test stuff. ill just not commit to the repo which is easy enough Razz

Second is there a way to hook into the dcs gui routines for say 3lvl greyscale. its a pipe dream but i would love to throw everything into greyscale that isnt the active window. I feel it looks cleaner. (note mouse hooks)

ill start with this for now. ill have more just in the clouds today
- The Doors CS GUI stuff inside Doors CS is mostly in startmenu.inc
- The way you would have to do grayscale is set up a GUI, call RenderGUI, then draw your own grayscale stuff on top of it and handle input. RenderGUI just renders the GUI stuff without going into an interactive mode. GUIMouse, on the other hand, renders the GUI and then launches the mouse, and will block until the user clicks on something. You could possibly use the mousehook for grayscale, but there's no great guarantee on how often it fires. You'd need to experiment
Ok to start your lack of comments on the startmenu.inc are pitiful Sad makes understanding it a nightmare. Second I figured out how I'm going to do greyscale and I plan on making a tech demo for that soon as
I get the dcsgui happy and understood I think i might benifit from just starting to make code up as I go. [s]I am lost on the guifindfirst/next you say the find the first item on the stack. Does that mean the first item of the top most Group Master ?[/s]

Got that answered new question. Are the dcs windows a set dimension? (eg one size for guirsmall and one for guirlarge)

And what are the RElocatablePTr and RelocatablePTR2 ?
Well, I put in comments when something is not clear to current or future me, and I found everything in startmenu.inc pretty straightforward. Razz The Doors CS source code is mostly designed for my own consumption at this point. Are you still lost on GUIFindFirst/GUIFindNext?

Yes, the windows are a fixed size; there are three sizes: GUIRFullScreen, GUIRLargeWin, and GUIRSmallWin. RelocatablePtr and RelocatablePtr2 are OS abstractions that the GUI needs to be not touched to keep memory in order. They're updated whenever the OS performs an _InsertMem or _DelMem.
according to the wiki GUIRFullScreen is GUIRLargeWin

Second is there a way to figure out what the current groupmaster would be? Or can i get a simple layout of what the appvar looks like so i can see how I would traverse it? Im assuming its [typeid],[stuff],[for],[the],[item],[type id],[etc] Correct?
geekboy1011 wrote:
according to the wiki GUIRFullScreen is GUIRLargeWin
Nope. GUIRFullScreen has no decoration and gives you 96x64 pixels to work with. GUIRLargeWin has the large window decorations and border.

Quote:
Second is there a way to figure out what the current groupmaster would be? Or can i get a simple layout of what the appvar looks like so i can see how I would traverse it? Im assuming its [typeid],[stuff],[for],[the],[item],[type id],[etc] Correct?
It's [size], [typeid], [data]. But You really should be storing what the current groupmaster is or at least know. It shouldn't be a surprise what type of groupmaster you're in, or even something you would need to figure out.
I'm just going to have to store it some where. Tho I can probably hard code it as all greyscale will be using GUIRSmallWin and be greyscalling the background. I needed to know so i knew where to skip oring bytes Razz Maybe I'll have the start of a tech demo up [s]tonight[/s] some time this weekend now that I have a second screen buffer to work with (between dcsblib Cn2 and DCSGUI you use all of the normal screen buffers Sad )
Yes, I do indeed; I figure that if you're using the DCS GUI it's unlikely that you'll need your own 768-byte screen buffer. Smile I think you should just store a byte somewhere, or even make yourself a little mini-stack if you anticipate layering a lot of windows together.
Runer112 suggested I use statvars+ the space after it. While it does wreck a few user variables that way its collateral damage in my honest opinion and as long as I document it as such I'm not worried (that is what readmes are for right? )
Ok update got my greyscale routine working Very Happy



And it works with the dcs GUI (hackishy but for my purposes quiet well)

Now with this I need a custom mouse routine. I can make the mouse routine that is not the problem But how would I make the dcsGUI handle click events and such?
I'm sad that you made my nice "rounded" corners go away, but I'll live with it. You shouldn't try to replicate all of my event-handling code; what you should do instead is have your mouse routine run, and when the user clicks, start up the normal GUIMouse with a mouse hook that does what the GUIMouse page describes "To force the GUIMouse to return control to your program from inside the hook, set the coordinates to an object that would cause it to exit anyway, and add an extra pop to the routine." Or you could just use the GUIMouse in general, and put your grayscale routine in the mouse hook. Or leave it running as an interrupt, and just make the mouse hook perform an ei.
Well with just leaving the interrupt running every time the mouse routine calls rendergui the grey scale dies due to the fastcopy in said routine. I will try the mouse hooks later im liking the first option you are suggesting. As that should not make the greyscale blip I hope and it makes sense to implement. Set coords to what my mouse routine has. Pop af then ret correct?
Yes, create a hook that sets the X and Y coordinates to what you want, pop whatever, and ret. Then run the GUIMouse with that hook, and everything should work correctly. There will be a slight blip, possibly, so make sure your hook also has an ei.
I gave a custom mouse routine a shot. This is how it ended up with nothing fancy other then just a blunt POC approach



Works only real gripe I have with it is that it draws the dcs mouse. Tho when I buffer the area the way I should it it should go away but yeah
That's odd; I'm not sure what's causing that. You could easily fix it with a quick RenderGUI right before you invoke your own mouse routine, I'm sure. Smile By the way, your mouse routine looks a bit slow to me; is that just an artifact of your screenshotting programs/emulator?
i tried calling rendergui before I draw my mouse it did not help with the issue and thats just how my mouse routine is atm I have it halting 6 times just to slow it down so it functions its really just a POC
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement