Jump to content
IGNORED

2018 Contest Chat


Recommended Posts

The rules say:

 

The games submitted do not necessarily need to be new, but must be your own work, not sold commercially or released in cartridge format previously.

 

I take that as even somewhat unfinished entries from the 2015 competition may qualify in improved versions for the 2018 competition, plus other projects previously disclosed outside of competition. Though I'd wait for the judges to weigh in on that.

Link to comment
Share on other sites

hmmm. I'm working on a coleco project at the moment but I was considering returning to that inty basic mr turtle game afterwards. Would you consider that eligible since I started it a while ago. Might motivate me to finish it.

Yes, Inty Mr Turtle would be eligible, finish that sucker ;)

Link to comment
Share on other sites

  • 4 weeks later...

I have a question regarding the rule of no ASM. I see that nanochess suggested to artrag that he could access internal music tracker memory structures via "PEEK" as a work around.

 

Should we really allow this?

 

My understanding was that the "no assembly" rule was to ensure that people were using IntyBASIC for programming, and that means only IntyBASIC features. If something is not exposed by IntyBASIC and a program tries to use it, then it's really not an IntyBASIC program, isn't it?

 

Consider this extreme example just to illustrate my point: What if I write a game in pure Assembly Language, assemble then disassemble it, convert it all into DATA statements and loaded it to RAM then trick the IntyBASIC runtime into directing control to it instead? Would that be an acceptable IntyBASIC program?

 

(I guess that wouldn't be easy to do, but I can't imagine it being impossible. I think it may be possible to create a "bootstrap" routine that could be overlaid on an IntyBASIC built-in routine via POKEing a bank-switch, then induce IntyBASIC into executing it. Or even easier: POKE the bootstrap into the ISR vector and hijack the runtime from the start...)

 

It's an exaggerated and silly example, but where do we draw the line on what is and isn't IntyBASIC? My suggestion is that it should be clear: Use only IntyBASIC statements, variables, constants, and other language-exposed facilities. PEEK and POKE should be constrained to access user-accessible memory.

 

-dZ.

Link to comment
Share on other sites

I have a question regarding the rule of no ASM. I see that nanochess suggested to artrag that he could access internal music tracker memory structures via "PEEK" as a work around.

 

Should we really allow this?

 

My understanding was that the "no assembly" rule was to ensure that people were using IntyBASIC for programming, and that means only IntyBASIC features. If something is not exposed by IntyBASIC and a program tries to use it, then it's really not an IntyBASIC program, isn't it?

 

Consider this extreme example just to illustrate my point: What if I write a game in pure Assembly Language, assemble then disassemble it, convert it all into DATA statements and loaded it to RAM then trick the IntyBASIC runtime into directing control to it instead? Would that be an acceptable IntyBASIC program?

 

(I guess that wouldn't be easy to do, but I can't imagine it being impossible. I think it may be possible to create a "bootstrap" routine that could be overlaid on an IntyBASIC built-in routine via POKEing a bank-switch, then induce IntyBASIC into executing it. Or even easier: POKE the bootstrap into the ISR vector and hijack the runtime from the start...)

 

It's an exaggerated and silly example, but where do we draw the line on what is and isn't IntyBASIC? My suggestion is that it should be clear: Use only IntyBASIC statements, variables, constants, and other language-exposed facilities. PEEK and POKE should be constrained to access user-accessible memory.

 

-dZ.

When ARTRAG asked it, I just noted the rules doesn't disallow POKE and PEEK.

 

Given the rules are now published, it would be unfair to change them as contest develops.

 

Edit: but not assembly language statements are allowed, that is anything tried to be hidden under DATA or any methods ;)

Link to comment
Share on other sites

When ARTRAG asked it, I just noted the rules doesn't disallow POKE and PEEK.

 

Given the rules are now published, it would be unfair to change them as contest develops.

 

Edit: but not assembly language statements are allowed, that is anything tried to be hidden under DATA or any methods ;)

 

Or... we could clarify the spirit of the rules of the contest. I do not think we need to be explicit in the rules about something like this. It should be clear that if there is no variable exposed for it, and no IntyBASIC mechanism to do it, it is not allowed.

 

No, PEEK and POKE are not disallowed, that's not the problem. They can be used to access the published memory map. The fact that he has to assemble, then read the "listing" file in order to get the memory location is also a red flag that goes against the spirit of the contest.

 

Personally I would disallow that out of principle. No reasonable person would even suggest that that is an "IntyBASIC" feature.

 

-dZ.

Link to comment
Share on other sites

 

Or... we could clarify the spirit of the rules of the contest. I do not think we need to be explicit in the rules about something like this. It should be clear that if there is no variable exposed for it, and no IntyBASIC mechanism to do it, it is not allowed.

 

No, PEEK and POKE are not disallowed, that's not the problem. They can be used to access the published memory map. The fact that he has to assemble, then read the "listing" file in order to get the memory location is also a red flag that goes against the spirit of the contest.

 

Personally I would disallow that out of principle. No reasonable person would even suggest that that is an "IntyBASIC" feature.

 

-dZ.

I'll suggest him to use a variable to keep the unreadable status.

 

Other than that I don't want to change rules during contest.

Link to comment
Share on other sites

DZ I think the spirit of the contest is to spread knowledge of the intellivision and promote the coding of new games for this funny ancient console, while the spirit of the rule that does not allow assembly is to make a common playfield among all the potential concurrent. But the spirit, as a such, is not a written rule and anyone could easily misinterpret it, as I think you could have done. So why not to stick to plain rules that say that the game has to be compiled with Intybasic v.1.2.9 and not include hand written ASM code?

Link to comment
Share on other sites

I use PEEK and POKE to get the value of the screen data to do my sprite to tile collision. So those 2 functions should be allowed.

Yes peek and poke should be allowed as they are available in the language. Helper ASM is disallowed, no matter how creative the programmer tries to be. There are multiple programmers on the judging committee and we will have access to the code since one of the stipulations is someone on the judging panel has to built it from source to replicate the submitted binary.

 

I think these two parts covers it:

 

"Your game(s) must be developed in IntyBASIC v1.2.9 and use the default prologue/epilogue files. The assembly language statements allowed within your game are the ORG statement so that you can develop a larger game and the CFGVAR statement to introduce metadata. "

 

"As part of the validation process, each entry's source code will be built using its instructions and the final binary produced must match the submitted binary image 100%. Any entry that fails this criteria will not be judged."

Link to comment
Share on other sites

When I say hand written asm I mean code written by the author of the submitted game, no matter if he is generating code with other tools or tricks.

The rule is needed to not give advantage to asm coders vs newcomers.

Apart from that, exploiting intybasic and its environment should be allowed if not welcome.

About compatibility with future versions of intybasic, it is not in the rules, but it will be my cure to update the sources or return any prize eventually won in case the game does not compile and run properly with the next intybasic releases.

Edited by artrag
Link to comment
Share on other sites

I use PEEK and POKE to get the value of the screen data to do my sprite to tile collision. So those 2 functions should be allowed.

 

 

Of course! From my comment:

No, PEEK and POKE are not disallowed, that's not the problem. They can be used to access the published memory map.

 

It's not the act of using PEEK and POKE that I thought should be disallowed, but the access to memory and data not exposed by either the known peripheral memory map or exposed by IntyBASIC. It is my opinion that direct manipulation of private variables used internally by IntyBASIC's runtime is an unwarranted advantage over someone who just uses stock IntyBASIC.

 

-dZ.

Link to comment
Share on other sites

The sole reason to disallow the access to the intybasic working ram is the potential compatibility with next versions of the compiler. That is not in the rules.

Provided that the compiler version is strictly defined by the rules themselves and that the goal of the competition is to spread the knowledge and the interest for the console, giving to non asm coders equal opportunity to asm coders, I do not see your point. Unless you are just trolling for the fun of it.

Link to comment
Share on other sites

The sole reason to disallow the access to the intybasic working ram is the potential compatibility with next versions of the compiler. That is not in the rules.

Provided that the compiler version is strictly defined by the rules themselves and that the goal of the competition is to spread the knowledge and the interest for the console, giving to non asm coders equal opportunity to asm coders, I do not see your point. Unless you are just trolling for the fun of it.

 

Thank you for making this personal. Up until this point, various people have expressed their opinions, as did I.

 

I disagree with you that the "sole reason to disallow the access to IntyBASIC working ram is the potential compatibility with next version of the compiler." In my opinion, and based on discussions we've had since last year's contest, the reason is to level the playing field by forcing everyone to use the same version of IntyBASIC and only IntyBASIC facilities.

 

I still assert that accessing internal private variables of the runtime goes against this, but that is just my opinion. I also assert that this is enshrined in the phrasing of this rule:

 

 

Your game(s) must be developed in IntyBASIC v1.2.9 and use the default prologue/epilogue files. The assembly language statements allowed within your game are the ORG statement so that you can develop a larger game and the CFGVAR statement to introduce metadata. However, bank switching is not permitted.

 

I accept that it does not say this specifically, but it also does not say that you cannot enhance the prologue/epilogue files or expand them, just that you must use the default ones. No reasonable person would suggest that it should also explicitly state "you must use the default prologue/epilogue files without modifications," and that without that last part there is a loophole. The same with this issue.

 

In every contest there is always a discretion of the judges to apply the rules as they best understand them. Oscar has already stated he believes the rules do not apply this point, and so I was trying to explain to him why I believe they do. Why is that trolling?

 

I never suggested that you were trying to cheat or find loopholes in the rules, I merely pointed out that Oscar was offering a suggestion for an enhancement that I thought went against the rules and that we shouldn't allow it. That is all.

 

Now I ask to everyone, will it really be so bad if people were not allowed to access private variables of the runtime by obtaining their values from the compiled assembly listing? I believe that the worst case scenario is that it prevents people from using a feature or performing a function that the stock IntyBASIC does not already provide -- which is par for the course for anybody using IntyBASIC, newbies and veterans. And that, in my opinion, is what the rules are trying to establish. Others may disagree.

 

-dZ.

Link to comment
Share on other sites

The sole reason to disallow the access to the intybasic working ram is the potential compatibility with next versions of the compiler. That is not in the rules.

Provided that the compiler version is strictly defined by the rules themselves and that the goal of the competition is to spread the knowledge and the interest for the console, giving to non asm coders equal opportunity to asm coders, I do not see your point. Unless you are just trolling for the fun of it.

Thank you for making this personal. Up until this point, various people have expressed their opinions, as did I.

Both of you please don't make it personal.

 

It's my fault to not make rules more strict, it's allowed by the rules this year, although not recommended, but I'll make sure next year the rules are stricter.

 

It's up to ARTRAG if he wants to run by the side of rules, but I've recommended him to not.

 

Nothing to see here, let us go back to developing games :)

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

In the Slalom thread (http://atariage.com/forums/topic/247376-entry-2015-slalom/) this animation is shown post-111-0-43675300-1521511455.gif

 

(not sure how to link straight to the actual post). Was this done with IntyBasic and if so, is the source code available?

 

if not, anybody got code to explain the basics of how to do this?

 

I am looking to scroll things on different lines at different speeds. possibly with different colors and maybe in different directions. but straight left to right and right to left.

Link to comment
Share on other sites

In the Slalom thread (http://atariage.com/forums/topic/247376-entry-2015-slalom/) this animation is shown post-38229-0-58342200-1434863941.gif

 

(not sure how to link straight to the actual post). Was this done with IntyBasic and if so, is the source code available?

 

if not, anybody got code to explain the basics of how to do this?

 

I am looking to scroll things on different lines at different speeds. possibly with different colors and maybe in different directions. but straight left to right and right to left.

Given the number of objects in screen at same time, this is done with 16 GRAM predefined.

 

The object is moved one bit to right for 8 times, the extra goes into another card.

 

Then you use an array to select the card for the pixel coordinate AND 7.

 

Essentially infinite objects of same type on screen.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...